Фаззинг веб-приложений на практике

[Tartuga]

Одна из стадий аудита веб-приложений – это, как известно, фаззинг. В данной статье я хочу рассказать о практической стороне фаззинга, показать, как это работает, и как искать баги, используя данную технику тестирования веб-приложений. Также рассмотрю некоторые средства автоматизации и программу “Fuzzer”, которая призвана частично автоматизировать процесс фаззинга веб-приложения. Статья будет полезна для специалистов уровня Junior.



Чтобы иметь общее представление о фаззинге, необходимо затронуть теоретическую часть и ответить на ряд вопросов.

Что такое фаззинг?



Фаззинг – это техника тестирования приложений путем передачи на вход приложения различных специально сгенерированных данных.

Какие цели преследует фаззинг?

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

Что фаззить? Не сувать куда попало

В случае, если речь идет о веб-приложениях, фаззить можно POST и GET параметры, заголовки и куки.

На что обратить внимание при фаззинге?



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

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

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

Что такое полезная нагрузка (Payload)?



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



Стандартные полезные нагрузки, используемые для фаззинга:

• одинарные и двойные кавычки – ', '';
• квадратные скобки – [];
• нулевой байт и другие символы в URL-кодировке - %00, %0d, %0a, %2522;
• boolean значения – True, False, 1, 0;
• отрицательные и большие числа – -123, 9999999999999999, 0.55 и т.д.

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

Пример 1

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

Код:

Пожалуйста Авторизуйтесь или Зарегистрируйтесь для просмотра скрытого текста.

В данном случае попробуем передать массив в параметре page с целью попытаться вызвать ошибку, с учетом того, что на сервере включен режим отладки, то есть Debug=True.

В результате удалось вызвать ошибку. Изучив ошибку, становится понятно, что данный параметр обрабатывается php функцией include(), которая позволяет подключать файлы и выполнять php код в файлах. Например, попробуем реализовать уязвимость типа LFI. Подключаем файл /etc/passwd находящийся на целевой системе за пределами веб-директории.

Пример 2

В процессе аудита бывают ситуации, когда при переходе на некоторые страницы, можно обнаружить множество ошибок.

В данном случае следует попытаться найти GET и POST параметры, которые могут использоваться на данной странице. Для поиска параметров нам понадобятся Intruder приложения Burp Suite, словарь с параметрами и выше перечисленные полезные нагрузки.

В результате перебора, при передаче GET параметра user наблюдается изменение длины ответа от веб-сервера, что скорее всего говорит о его наличии. Согласно примеру, параметр page уязвим для атаки типа SQL injection, а ошибки изначально возникли из-за того, что параметр не был установлен.

Пример 3

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

Путь из ошибки может понадобиться для составной атаки. Например, если есть возможность писать в файл через SQL injection, то понадобится полный локальный путь до файла.



Пример 4

В следующем примере рассмотрим запрос, который содержит GET параметр id. При запросе без внедрения полезной нагрузки, сервер отвечает достаточно массивным ответом, длиной 135 011 байт. Такой ответ не удобно анализировать, так как каждый раз необходимо просматривать его содержимое. В таких случаях удобнее ориентироваться на изменения в длине ответа от веб-сервера.

Код:

Пожалуйста Авторизуйтесь или Зарегистрируйтесь для просмотра скрытого текста.

Например, если передать одинарную кавычку в параметр id=19' можно заметить, что длина ответа резко изменилась. Это говорит о возможном возникновении некоторой аномалии.

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

Пример 5

Это пример не совсем относится к теме фаззинга, но я решил его рассмотреть. Часто разработчики, внося изменения в работу веб-приложений, оставляют для себя backup файлы, забывая их удалять. Потом эти файлы оказываются доступными всем пользователям через браузер. Например, после того как мы провели перебор файлов с расширением php, были найдены: news.php, test.php, index.php. Используя список популярных бак расширений, пробуем найти backup файлы. Для этой задачи можно использовать Intruder, но как по мне, наиболее удобным инструментом является Gobuster.

Рассмотрим некоторые флаги, которые были переданы в команде выше:

• w – принимает словарь с найденными php файлами;
• u – принимает url, где будем искать бак файлы;
• x – принимает список бак расширений, которые мы ищем.

В результате мы нашли несколько backup файлов, забытых разработчиком: test.php.gz, news.php.old, index.php.bak. Содержимое файлов как правило можно просмотреть, а путем анализа исходного кода выявить серьезные уязвимости, которые сложнее найти методом Black Box. Также backup файлы могут содержать конфиденциальные данные.

Пример 6

Пример не отображает процесс фаззинга, однако показывает, что чувствительные данные могут передаваться не только через GET или POST параметры. Например, в запросе ниже в URL передается некоторый набор цифр, в данном случае это ИИН человека. В ответ на такой запрос сервер возвращает персональные данные человека по переданному ИИН.

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

Методы защиты от фаззинга:

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

Инструменты для автоматизации процесса фаззинга:

• burp suite (Intruder);
• gobuster;
• самописные скрипты;
• и т.д.

Я есть Fuzzer



Ссылка на инструмент:

Пожалуйста Авторизуйтесь или Зарегистрируйтесь для просмотра скрытого текста.

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

Особенности инструмента:

• фаззит GET параметры, POST параметры, POST параметры в JSON формате;
• Fuzzer определяет тип данных каждого переданного параметра, всего он может определить 4 типа данных (integer, float, string, boolean). В зависимости от типа данных будут подключаться наиболее подходящие полезные нагрузки для фаззинга;
• каждый пользователь может самостоятельно расширять свои полезные нагрузки и указать куда именно в параметр или его значение подставлять полезную нагрузку;
• можно передать весь запрос из Burp Suite (на случай если нужно использовать определенные cookies и headers), Fuzzer самостоятельно его распарсит и проффазит;
• помимо принятия запроса из Burp Suite, флаг –burp позволяет вернуть результаты фаззинга обратно в Burp Suite, что позволит их моментально проанализировать;
• поддержка многопоточности и проксирование;
• используя параметр –payloads, имеется возможность передавать программе пользовательский словарь с полезными нагрузками для фаззинга. Для указания параметра, который необходимо фаззить по пользовательскому словарю используются * или **, в зависимости от того, нужно ли сохранять значение параметра при фаззинге.

Что еще будет добавлено в Fuzzer:

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

Если вы нашли баги или у вас есть идеи как сделать Fuzzer лучше, напишите мне, вместе мы решим этот вопрос.

Ссылки на различные словари:

Пожалуйста Авторизуйтесь или Зарегистрируйтесь для просмотра скрытого текста.

Пожалуйста Авторизуйтесь или Зарегистрируйтесь для просмотра скрытого текста.

Пожалуйста Авторизуйтесь или Зарегистрируйтесь для просмотра скрытого текста.

Пожалуйста Авторизуйтесь или Зарегистрируйтесь для просмотра скрытого текста.