Представляю вашему вниманию очередную часть перевода OWASP Testing Guide. В данной статье речь пойдет об обходе аутентификации.

 

Предыдущие статьи
  1. Тестирование: введение и задачи
  2. Сбор информации с помощью поисковых систем
  3. Определение веб-сервера
  4. Поиск информации в метафайлах веб-сервера
  5. Определение веб-приложений на сервере
  6. Поиск утечек информации в комментариях и метаданных
  7. Определение точек входа веб-приложения
  8. Составление карты веб-приложения
  9. Определение фреймворка веб-приложения
  10. Определение веб-приложения
  11. Составление карты архитектуры веб-приложения
  12. Тестирование конфигурации инфраструктуры веб-приложения
  13. Изучение расширений файлов
  14. Поиск страрых версий веб-приложения, скрытых файлов и резервных копий
  15. Поиск административных интерфейсов
  16. Тестирование HTTP методов
  17. Тестирование HSTS
  18. Тестирование кросс-доменной политики
  19. Изучение ролей пользователей
  20. Тестирование процесса регистрации
  21. Предоставление учетных записей
  22. Определение имен пользователей
  23. Определение правил генерации имен пользователей
  24. Изучение передачи пользовательских данных
  25. Тестирование учетных данных по умолчанию
  26. Изучение механизма блокировки учетных записей

 


Резюме

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

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

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

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

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

  • На этапе развертывания проблемы могут возникнуть на этапе установки и настройки из-за отсутствия необходимых технических знания или отсутствия хорошей документации

Как тестировать
Тестирование по методу черного ящика

Существует несколько методов обхода аутентификации в веб-приложениях:

  • Запрос страницы напрямую (подбор директорий или файлов)

  • Изменение параметра

  • Предсказание ID сессии

  • SQL инъекция

Запрос страницы напрямую

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

Изменение параметра

Еще одной проблемой проэктирования аутентификации является то, что веб-приложение определяет успешную авторизацию исходя из фиксированных значений параметров. Пользователь может изменить значения этих параметров для получения доступа к закрытым частям веб-приложения без предоставления правильных учетных данных. В примере приведенном ниже значение параметра «authenticated» было изменено на «yes», который позволяет пользователю получить доступ. В данном примере используется GET параметр, для изменения POST параметров или значений куки нужно использовать перехватывающий прокси.


http://www.site.com/page.asp?authenticated=no


raven@blackbox /home $nc www.site.com 80
GET /page.asp?authenticated=yes HTTP/1.0

HTTP/1.1 200 OK
Date: Sat, 11 Nov 2006 10:22:44 GMT
Server: Apache
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC «-//IETF//DTD HTML 2.0//EN»>
<HTML><HEAD>
</HEAD><BODY>
<H1>You Are Authenticated</H1>
</BODY></HTML>

Предсказание ID сессии

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

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

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

SQL инъекция

SQL инъекция — широко известная атака, но в данной статье она не будет рассмотрена подробно. Данная атака будет описана позднее в рамках данного гайда.

На картинке ниже показана простая SQL инъекция с помощью которой иногда можно обойти форму авторизации.

Тестирование по методу серого ящика

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

В следующем примере (PHPBB 2.0.13 — Authentication Bypass Vulnerability), на пятой строке функция unserialize() парсит куки, предоставленные пользователем, и устанавливает значения в массиве $row. На 10 строке MD5 пароля, сохраненный в базе, сравнивается с предоставленным пользователем.


1. if ( isset($HTTP_COOKIE_VARS[$cookiename . '_sid']) ||
2. {
3. $sessiondata = isset( $HTTP_COOKIE_VARS[$cookiename . '_data'] ) ?
4.
5. unserialize(stripslashes($HTTP_COOKIE_VARS[$cookiename . '_data'])) : array();
6.
7. $sessionmethod = SESSION_METHOD_COOKIE;
8. }
9.
10. if( md5($password) == $row['user_password'] && $row['user_active'] )
11.
12. {
13. $autologin = ( isset($HTTP_POST_VARS['autologin']) ) ? TRUE : 0;
14. }

В PHP сравнение строки и булевого значения (1 — «TRUE») всегда возвращает правду, поэтому можно обойти аутентификацию отправив следующую строку (важная часть — это «b:1») в функцию unserialize():


a:2:{s:11:"autologinid";b:1;s:6:"userid";s:1:"2";}

Инструменты

Рекомендации
Информационные бюллетени