Введение
В безопасности веб-приложений обнаружение скрытых или недокументированных GET-параметров имеет решающее значение для выявления потенциальных уязвимостей. Эти параметры иногда могут приводить к раскрытию информации, SQL-инъекциям или другим уязвимостям безопасности, если приложение обрабатывает их некорректно. Gobuster, популярный инструмент для перебора каталогов и файлов, также предлагает режим "fuzz" (фаззинг), который можно использовать для обнаружения GET-параметров.
Эта лаборатория проведет вас через процесс использования режима fuzz в Gobuster для идентификации GET-параметров. Вы научитесь составлять URL с ключевым словом FUZZ, использовать список слов с распространенными именами параметров, выполнять сканирование и анализировать результаты для поиска интересных параметров. К концу этой лаборатории вы получите практическое понимание того, как выполнять фаззинг GET-параметров с помощью Gobuster, что является ценным навыком для любого энтузиаста или профессионала в области кибербезопасности.
Определение целевой конечной точки URL для тестирования
На этом шаге вы определите целевую конечную точку URL, которую хотите протестировать на наличие скрытых GET-параметров. Для этой лаборатории мы будем использовать простой веб-сервер, который имитирует уязвимое приложение. Мы запустим HTTP-сервер Python для обслуживания базового HTML-файла.
Сначала перейдите в каталог вашего проекта:
cd ~/project
Далее создайте простой HTML-файл с именем index.html, который мы будем использовать в качестве цели. Этот файл будет имитировать веб-страницу, которая может принимать GET-параметры.
nano index.html
Добавьте следующее содержимое в index.html:
<!DOCTYPE html>
<html>
<head>
<title>Test Page</title>
</head>
<body>
<h1>Welcome to the Test Page!</h1>
<p>This page is for testing GET parameters.</p>
</body>
</html>
Сохраните файл, нажав Ctrl+X, затем Y и Enter.
Теперь запустите простой HTTP-сервер Python для обслуживания этого файла. Этот сервер будет работать на порту 8000.
python3 -m http.server 8000 &
Символ & в конце запускает сервер в фоновом режиме, позволяя вам продолжить работу в терминале. Вы должны увидеть вывод, похожий на этот:
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
Целевой конечной точкой URL для нашего фаззинга будет http://127.0.0.1:8000/index.html.
Создание URL с ключевым словом FUZZ в качестве имени параметра
На этом шаге вы научитесь создавать URL, который Gobuster будет использовать для фаззинга. Режим fuzz в Gobuster требует ключевое слово FUZZ в URL, чтобы указать, куда должны вставляться записи из списка слов (wordlist). При фаззинге GET-параметров ключевое слово FUZZ заменяет имя параметра.
Базовый формат GET-запроса с параметром выглядит так: http://example.com/path?parameter=value. Чтобы выполнить фаззинг имени параметра, мы заменим parameter на FUZZ. Значение может быть любым, поскольку нас интересует только обнаружение самого имени параметра. Распространенной практикой является использование простого значения, такого как 1 или test.
Для нашей лаборатории целевым URL является http://127.0.0.1:8000/index.html. Для фаззинга имен GET-параметров URL будет сконструирован следующим образом:
http://127.0.0.1:8000/index.html?FUZZ=test
Здесь:
http://127.0.0.1:8000/index.html— это наш базовый URL.?обозначает начало строки запроса (query string).FUZZ— это заполнитель, куда Gobuster будет вставлять слова из нашего списка слов.=test— это статическое значение для параметра. Конкретное значение не имеет значения для обнаружения имени параметра, но оно требуется для корректного формата параметра.
Вам не нужно выполнять никаких команд на этом шаге, но понимание построения этого URL имеет решающее значение для следующих шагов.
Использование списка слов с распространенными именами параметров
На этом шаге вы подготовите список слов (wordlist), содержащий распространенные имена GET-параметров. Gobuster будет перебирать этот список слов, заменяя ключевое слово FUZZ в URL каждым словом из списка.
Хотя Gobuster часто поставляется с набором списков слов по умолчанию, полезно знать, как создавать или указывать свои собственные. Для этой лаборатории мы создадим небольшой пользовательский список слов с некоторыми распространенными именами параметров.
Сначала убедитесь, что вы находитесь в каталоге ~/project:
cd ~/project
Теперь создайте новый файл с именем params.txt, который будет служить нашим списком слов:
nano params.txt
Добавьте следующие распространенные имена параметров в params.txt, каждое на новой строке:
id
name
user
page
search
query
file
data
token
Сохраните файл, нажав Ctrl+X, затем Y и Enter.
Этот файл params.txt будет использоваться Gobuster на следующем шаге для фаззинга GET-параметров.
Выполнение сканирования Gobuster fuzz
На этом шаге вы выполните сканирование Gobuster fuzz, используя сконструированный URL и список слов.
Команда для режима fuzz в Gobuster — gobuster fuzz. Нам нужно указать URL с ключевым словом FUZZ с помощью флага -u и список слов с помощью флага -w.
Откройте терминал и выполните следующую команду:
gobuster fuzz -u http://127.0.0.1:8000/index.html?FUZZ=test -w ~/project/params.txt
Разберем команду:
gobuster fuzz: Запускает Gobuster в режиме фаззинга.-u http://127.0.0.1:8000/index.html?FUZZ=test: Указывает целевой URL с заполнителемFUZZ.-w ~/project/params.txt: Указывает путь к нашему списку слов, содержащему имена параметров.
Gobuster теперь будет отправлять запросы на веб-сервер, заменяя FUZZ каждым словом из params.txt. Поскольку наш index.html на самом деле не обрабатывает эти параметры, Gobuster, скорее всего, сообщит одинаковый код состояния и длину содержимого для всех запросов. Однако в реальных условиях изменение кода состояния или длины содержимого будет указывать на то, что параметр может быть распознан.
Вывод покажет каждую попытку и соответствующий код состояния и длину содержимого. Он будет выглядеть примерно так:
===============================================================
Gobuster vX.X.X
===============================================================
[+] Url: http://127.0.0.1:8000/index.html?FUZZ=test
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /home/labex/project/params.txt
[+] Status codes: 200,204,301,302,307,401,403,405
[+] User Agent: gobuster/X.X.X
[+] Timeout: 10s
===============================================================
200 (290) - http://127.0.0.1:8000/index.html?id=test
200 (290) - http://127.0.0.1:8000/index.html?name=test
200 (290) - http://127.0.0.1:8000/index.html?user=test
200 (290) - http://127.0.0.1:8000/index.html?page=test
200 (290) - http://127.0.0.1:8000/index.html?search=test
200 (290) - http://127.0.0.1:8000/index.html?query=test
200 (290) - http://127.0.0.1:8000/index.html?file=test
200 (290) - http://127.0.0.1:8000/index.html?data=test
200 (290) - http://127.0.0.1:8000/index.html?token=test
===============================================================
Анализ результатов на предмет изменений длины ответа или статуса
На этом шаге вы научитесь интерпретировать вывод сканирования Gobuster fuzz. Ключ к выявлению потенциально допустимых или интересных GET-параметров заключается в наблюдении за изменениями в HTTP-ответе.
Когда Gobuster работает, он отображает HTTP-код состояния и длину содержимого (в байтах) для каждого отправляемого им запроса.
Например, вывод из предыдущего шага показал:
200 (290) - http://127.0.0.1:8000/index.html?id=test
200 (290) - http://127.0.0.1:8000/index.html?name=test
...
Здесь 200 — это HTTP-код состояния (OK), а 290 — длина содержимого ответа.
На что обращать внимание:
- Различные коды состояния: Если запрос с определенным именем параметра возвращает другой HTTP-код состояния (например,
200для допустимого,404для не найденного,500для ошибки сервера,302для перенаправления), это может указывать на то, что приложение обработало или отреагировало на этот параметр. Например,200 OKдля параметра, который обычно возвращает404 Not Found, может быть значимым. - Различные длины содержимого: Даже если код состояния остается
200 OK, изменение длины содержимого может быть сильным индикатором. Это часто означает, что тело ответа приложения изменилось, возможно, путем включения конкретных данных, связанных с параметром, сообщения об ошибке или другого макета страницы. - Сообщения об ошибках: Иногда параметр может вызвать сообщение об ошибке (например, ошибку SQL, ошибку приложения), которое отражается в теле ответа, что приводит к другой длине содержимого или даже коду состояния
500. Это является сильным признаком потенциальной уязвимости.
В нашей текущей лабораторной установке, поскольку index.html является статическим файлом, а сервер Python не обрабатывает GET-параметры, вы увидите, что все запросы возвращают код состояния 200 и одинаковую длину содержимого (290 байт). Это ожидаемое поведение для нашего простого тестового случая.
В реальных условиях, если бы вы фаззили действующее веб-приложение и увидели запись вроде:
200 (512) - http://example.com/search?query=test
в то время как другие параметры возвращали 200 (290), параметр query стоило бы исследовать дальше из-за другой длины содержимого.
Этот шаг завершает лабораторию. Вы успешно научились использовать Gobuster для фаззинга GET-параметров и анализировать результаты.
Чтобы остановить сервер Python HTTP, вы можете найти его идентификатор процесса (PID) и завершить его. Сначала выведите список запущенных процессов Python:
ps aux | grep "python3 -m http.server 8000"
Вы увидите вывод, похожий на:
labex 1234 0.0 0.0 12345 6789 ? S HH:MM 0:00 python3 -m http.server 8000
Запишите PID (например, 1234 в этом примере) и затем завершите процесс:
kill 1234
Замените 1234 на фактический PID, который вы нашли.
Резюме
В этой лаборатории вы успешно научились выполнять фаззинг GET-параметров с помощью Gobuster. Вы начали с настройки локального веб-сервера и создания целевого HTML-файла. Затем вы сконструировали URL с ключевым словом FUZZ, подготовили пользовательский список слов с распространенными именами параметров и выполнили сканирование Gobuster fuzz. Наконец, вы научились анализировать результаты сканирования, уделяя особое внимание изменениям HTTP-кодов состояния и длин содержимого, которые являются ключевыми индикаторами распознанных параметров.
Этот метод является фундаментальной частью разведки веб-приложений и может помочь выявить скрытые функциональные возможности или потенциальные уязвимости. Освоив этот навык, вы будете лучше подготовлены к выявлению и исследованию поверхностей атаки веб-приложений.
