Введение

Чтобы идентифицировать личность в группе людей, нам необходима любая уникальная комбинация вводных, с помощью которой мы можем это сделать. Эта комбинация может быть его именем, фамилией, адресом или номер социального страхования. Это всё является данными, которые могут помочь пользователям однозначно идентифицировать себя. Перечисленное относится к людям в реальной жизни, но что если мы хотим идентифицировать себя в веб-приложении. Для этого веб-приложения используют такое понятие как «Аутентификация».  

Что такое аутентификация? 

В случае веб-приложений используются разнообразные методы аутентификации, это может быть как имя пользователя, пароль или имя пользователя с одноразовым паролем, отправленным на ваш мобильный телефон. Если какой-либо злоумышленник знает ваше имя пользователя и пароль или другие факторы, которые вы используете для аутентификации, он может легко выдать себя за вашу личность. 

«Аутентификация» — это процесс, который подтверждает вашу личность в цифровом пространстве.

Злоумышленники стремятся получить доступ к вашей аутентификационной информации для выполнения задач, не разрешенных вами. 

Простой пример обхода аутентификации: есть некоторые веб-страницы или функции, к которым можно получить доступ только после входа в систему, но как только злоумышленник посещает эту страницу напрямую в обход интерфейса, существует вероятность, что аутентификация там может не работать. Проблемы, связанные с аутентификацией, могут возникать на разных этапах SDLC (жизненного цикла программного обеспечения). 

Этап проектирования

На этом этапе команда решает, как реализовать новую функциональность в приложении, например, планируя архитектуру программного обеспечения, и аутентификация является одной из составляющих. 

Владельцы приложений (стэйкхолдеры) решают, как будет выполняться аутентификация в приложении. 

Этап разработки

Это этап, когда разработчик начинает реализовывать аутентификацию с помощью кода, и им необходимо следить за её правильной реализацией. Если аутентификация не настроена должным образом, это может представлять угрозу для организаций и может привести к обходу проверок аутентификации. 

Фаза развертывания приложения

Eсли аутентификация не была настроена должным образом, в этом случае злоумышленник может извлечь из этого выгоду, например получить доступ к учетной записи пользователя, а затем выполнить несанкционированные действия. 

Различные сценарии для проверки аутентификации 

Тестирование аутентификации означает понять, как работает аутентификация, а затем попытаться использовать некоторые обходные пути, чтобы проверить, корректно ли она реализована. Например, определить какие способы использует приложение для аутентификации пользователя, и сколькими способами приложение принимает пользовательские данные, каков алгоритм работы с этой информацией, какой метод использует приложение для выполнения аутентификации после предоставления учетных данных. 

• Ссылки прямого доступа/ Directly accessible links.

В этом случае злоумышленник может напрямую получить доступ к непубличной веб-странице или напрямую запросить данные другой страницы, используя форсированный браузинг (forced browsing). 

Это происходит, когда разработчик приложения реализует функцию проверки аутентификации исключительно на странице входа, поэтому, когда злоумышленник отправляет запрос на любую другую страницу, эта страница может не проверять, прошел ли пользователь аутентификацию или нет, и в этом случае аутентификация игнорируется. 

• Модификации параметра запроса/ Modification in the request parameter.

Аутентификация в основном базируется на фиксированных параметрах для успешного входа в систему, таких как определённые файлы cookie или JWT токены (JSON Web Token), и злоумышленники пытаются изменить значение этих параметров, чтобы получить доступ к внутренней веб-странице. Следовательно, в этом случае злоумышленникам не нужно вводить действительные учетные данные для доступа. 

Например, перехват страницы приложения, к которой у злоумышленника пока нет доступа. Изучив детальнее приложение, злоумышленник заметил, что один из передаваемых параметров имеет имя «isAutheticationRequired». По умолчанию его значение установлено на «ДА», но если злоумышленник изменит значение этого параметра на «Нет», доступ к странице возможен и без аутентификации. 

• Предсказуемый идентификатор сессии/ Predictable Session Id.

Аутентификация в приложении контролируется идентификатором сессии, который назначается пользователю после проверки его учетных данных, и это работающий способ поддерживать аутентификацию активной. Но если приложение назначает предсказуемый идентификатор сессии, то злоумышленник может предсказать следующий идентификатор, который может быть назначен другому пользователю, и получить доступ к учетной записи и выдать себя за законного пользователя. 

• SQL-инъекция/ SQL injection.

Это очень популярная уязвимость с высоким риском, которая может существовать в веб-приложении. Иногда злоумышленник так же может получить доступ и к учетной записи администратора. 

Успешная SQL-инъекция может обновить, изменить или удалить базу данных. 

Больше о SQL-инъекциях можно прочитать в блоге автора. 

• Небезопасная десериализация/ Insecure Deserialization.

*Сериализация (в программировании) — процесс перевода структуры данных в битовую последовательность.  
**Обратной к операции сериализации является операция десериализации (структуризации) — создание структуры данных из битовой последовательности. 

В случае небезопасной десериализации при преобразовании потока байтов в объект данных, уязвимость может быть использована для изменённой проверки пользователя и его контроля доступа к приложению. 

Возьмем пример: есть приложение, которое принимает данные без какой-либо дополнительной обработки или проверки, так же исключая проверку битовой последовательности. Во время входа в данную систему тип файла cookie назначается пользователю и этот файл кодируется в base64, поэтому для фактического его декодирования вам потребуется декодер base64. После расшифровки cookie выглядит так. 

a:2:{s:7:"isAdmin";b:5:"False";s:6:"userid";s:1:"2";} 

Теперь, злоумышленник может изменить значение параметра «isAdmin» на True и значение «b» на 4, а затем снова закодировать указанное выше значение в base64. Как уже упоминалось выше, на сервере, обрабатывающем запрос злоумышленника, не происходит проверки. Злоумышленники получат доступ к веб-страницам доступным только администратору. 

Подробнее о небезопасной десериализации можно прочитать в блоге автора.

• Распыление паролей/ Password Spraying.

Распыление паролей — это атака, при которой злоумышленник использует пароль и подбирает его для большого количества учетных записей.

Пользователи обычно используют слабые пароли, которые могут быть в словаре, поэтому в этом случае злоумышленник использует список известных паролей. Если пароль совпадает, злоумышленник сможет пройти аутентификацию, а затем получить доступ к учетной записи пользователя. 

Для перекрестной проверки злоумышленник обычно использует имена пользователей, такие как admin или administrator, поскольку он может иметь доступ ко всему приложению. Этот метод более опасен, так как многие организации используют реализацию SSO, поэтому, если злоумышленник получит доступ к любому провайдеру SSO, он может получить доступ ко всем учетным записям пользователя. 

• Заполнение учетных данных/ Credential Stuffing.

При заполнении учетных данных злоумышленники используют те учетные данные, которые просочились при каком-либо взломе, и пробуют их на разных веб-сайтах. 

Как нам известно, большинство пользователей используют одни и те же учетные данные в нескольких местах, и злоумышленники могут злоупотреблять этим поведением. Если учетные данные сработали для другой учетной записи того же пользователя, злоумышленник может получить доступ и к этой учетной записи пользователя тоже. Иногда, если пользователь использует один и тот же пароль на сайтах A и B и происходит утечка данных на сайте A, существует риск того, что злоумышленник может также скомпрометировать учетную запись пользователя на сайте B. 

Вывод 

Аутентификация — одна из самых важных функций в веб-приложении. Поэтому перед её реализацией программистам необходимо принять меры предосторожности заранее на стадии разработки. Данная статья перечислила различные виды, как можно обойти проверку аутентификации. Но данные уязвимости могут быть предотвращены, если следовать установленным требованиям и правилам безопасности веб-приложений, предоставленными OWASP и другими. Очень важно внедрить политики паролей во всей организации, чтобы избежать таких атак, как подмена учетных данных или распыление паролей.