• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

Статья Пентест веб-приложений: Исследование исходного кода веб-страниц. Определение точек входа. Карта приложения.

Исследование исходных кодов веб-страниц приложения.

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

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

Комментарии HTML в коде начинаются с символов <!-- и заканчиваются -->:
<!-- это комментарий html -->

Комментарии javascript бывают однострочные, и следуют за двойным слэшем //
// однострочный комментарий javascript

И бывают многострочные, которые заключаются между символами /* и */
Код:
/* это многострочный
комментарий */

Кроме комментариев в коде стоит обратить внимание на теги <meta> (они так же могут содержать полезную информацию), скрипты (к примеру, можно обнаружить подозрительный код на сайте или определить технологии, которые используются в приложении), пути к ресурсам приложения. Ниже я приведу несколько примеров.

Теги <meta> с атрибутом name="author" позволяют тестеру определить автора документа, его email. Такая информация может помочь в дальшейшем при подборе паролей к административным интерфейсам или скорректировать векторы атаки:
31412


31413


31414



Атрибут http-equiv тега <meta> позволяет изменять значения некоторых заголовков ответа веб-сервера. Браузер обрабатывает значение этого атрибута так, как будто бы это значение пришло непосредственно от сервера:
31415

В данном случае в коде веб-страницы устанавливаются следующие заголовки ответа:
Refresh — с помощью этого значения определяется время задержки, после которой браузер автоматически перезагрузит страницу. Дополнительно в теге можно указать, какой именно документ нужно загрузить. В данном случае (на скрине выше) без какой-либо задержки должен загружаться документ /server-manager.
Expires - дата устаревания документа, при наступлении которой браузер должен обратиться к серверу за новой версией страницы, а не брать ее из кэша. Значение, равное нулю, интерпретируется как «сейчас».
Cache-Control определяет, должен ли браузер кэшировать данную страницу.


Иногда информация может быть раскрыта в коде скриптов:
31416

в данном скрипте сожержится адрес, по которому, вероятно, находится тестовая версия приложения. При попытке доступа к странице по этому адресу запрашивается логин и пароль:
31417

Так же по данному url мы можем предположить, что CMS тестируемого приложения — 1c-bitrix.

А в данном скрипте был раскрыт путь от сайта до корня сервера и один из ip-адресов:
31418


Комментарии в js-скриптах или html-коде могут содержать учетные данные:
31419


Непонятно, почему логин и пароль в таком виде и что это за кодировка. Но если посмотреть на длину логина и пароля, то можно предположить, что это admin и pass, и в итоге предположение оказалось верным.

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


Определение точек входа приложения.

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

Для просмотра параметров, отправляемых в POST-заросах вы можете использовать встроенные средства браузера или перехватывающий прокси, такой как OWASP Zap или Burp. В POST-запросах особое внимание обратите на скрытые поля (hidden), в которых может передаваться конфиденциальная информация, или информация, которую по задумке разработчика вы не должны видеть и изменять.

Перед началом этого этапа тестирования составьте таблицу, в левую часть которой записывайте все запросы, а в правую все ответы на эти запросы. Это может быть утомительным и скучным занятием, но именно на этом этапе мы определяем, что и как мы будем тестировать дальше.
В таблице нужно отметить, является ли запрос GET или POST, все заголовки запросов и ответов, является ли доступ аутентифицированным или нет, используется ли SSL, является ли запрос частью многоэтапного процесса и другие замечания, которые покажутся вам важными. Так же обратите внимание, что в приложении могут использоваться и другие HTTP-методы, кроме GET и POST, например PUT или DELETE, которые могут представлять опасность для веб-приложения.

Чек-лист этого этапа выглядит так:

Запросы
- определите, где используются GET-запросы, где POST-запросы, используются ли другие HTTP-методы и в каких точках приложения
- определите все параметры, используемые в каждом POST-запросе
- определите все скрытые параметры POST-запроса. Обычно они не видны в браузере (то есть поля ввода для этих параметров не отображаются в окне браузера), но их можно увидеть в теле запроса, если использовать перехватывающий прокси. В зависимости от значений скрытых параметров может отличаться следующая страница, которая отдается серевером после выполнения запроса, может различаться уровень доступа или данные на странице
- определите все параметры, используемые в каждом GET-запросе. В частности строку запроса (которая обычно следует в URL после знака вопроса), cookie, host
- определите все параметры строки запроса. Они обычно представлены в форме пары параметр=значение, например foo=bar, id=123, page=10 и тд. Параметров может быть много и они могут быть разделены символом & или каким либо другим специальным символом

Важно определить все параметры, так как любой из них может оказаться уязвимым. Так же обратите внимание на нестандартные параметры, особенно в скрытых полях POST-запросов, такие как debug=false.


Ответы
- определите, где устанавливаются, добаляются или изменяются cookie
- определите, где сервер отвечает кодами состояния 300 (перенаправления), 400 (403 — доступ запрещен, 404 — файл не найден и тд), 500 (внутренние ошибки сервера) при обычных, то есть не измененных запросах
- обратите внимание на интересные заголовки. Например заголовок "Server: BIG-IP" указывает на то, что приложение использует балансировщик нагрузки

Примеры.
POST-запрос, просмотр средствами браузера. Можно просмотреть как заголовки запроса и ответа, так и параметры запроса.
Заголовки ответа:
31420


Заголовки запроса:
31421


Параметры запроса:
31422


Некоторые параметры в запросе выше являются скрытыми и их нельзя изменить через обычную форму ввода:
31423



GET-запрос. В запросе имеется два параметра - параметр id со значением 69545 и параметр veaction со значением edit:
31424



ЧПУ - человеко-понятные УРЛ, семантические URL
Человеко-понятный УРЛ - URL-путь, состоящий из понятных слов, вместо идентификаторов, и отражающий файловую структуру сайта. Например, вместо
/index.php?cat=10&subcat=2&id=41 будет /product/phone/Samsung/.
Такие URL все чаще можно встретить в современных веб-приложениях. В связи с этим возникает вопрос, как определять параметры GET-запросов, если приложение использует ЧПУ?
Частично на данный вопрос отвечает этот документ - .

Приведу один пример, в котором оказалось легко выявить параметры строки запроса. Ниже на скриншотах видим семантический URL:
31428


и тот же запрос в привычном виде, с параметром и значением id=5:
31429


Опять же можно попробовать поискать в Гугле. Такие проиндексированные URL могут дать некоторое понимание, как в приложении формируются запросы на самом деле:
31430





Карта приложения.

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

Сбор информации для составления карты удобно выполнять с помощью OWASP Zap:
31425


После того, как ZAP пройдется веб-пауком по всему сайту, можно выгрузить все найденные URL в отдельный текстовый файл. Структуру сайта и найденные точки входа можно просматривать в самом ZAP в навигационном окне слева. В окне справа можно просматривать каждый выполненый запрос и ответ.
Теперь на основе полученной информации можно составить карту. Я пробовал использовать для этого LibreOffice Draw и у меня получалось что-то вроде этого:
31426

Реальная карта должна быть более детализирована. Чем выше детализация, тем лучше.

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


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

У меня на сегодня все. Всем пока! )
 
Последнее редактирование:

c0mb0

Green Team
02.10.2018
52
19
BIT
13
Интересно, что только сканер от IBM, в отличии от Acunetix, шарит что нужно грабить <!-- КОММЕНТАРИИ //-->
и таки при скане всего сайта дает годные результаты, например закоментированные, но активные формы ввода и загрузки,
годного результата я добился настройкой парсера Datacol под конкретный сайт, обход всего сайта, сбор комментариев, ну и по регуляркам все мыла, телефоны, содержимое <script>, ссылки, даже если они не очевидны и работают через JS, токены и прочее
 
  • Нравится
Реакции: Crazy Jack и larchik

c0mb0

Green Team
02.10.2018
52
19
BIT
13
Еще добавлю, по листу ссылок типа, /main/rss.xml /rss.xml грабим RSS, а именно нас интересуют поля <autor> или подобные,
получаем админов\авторов ресурса, таким не хитрым способом сграбил юзер лист под CMS Data Life Engine (в самих постах имя автора нет), ну а дальше брут админок
 
Последнее редактирование:
  • Нравится
Реакции: centr и larchik

larchik

Администратор
07.06.2019
391
457
BIT
339
Еще добавлю, по листу ссылок типа, /main/rss.xml /rss.xml грабим RSS, а именно нас интересуют поля <autor> или подобные,
получаем админов\авторов ресурса, таким не хитрым способом сграбил юзер лист под CMS Data Life Engine (в самих постах имя автора нет), ну а дальше брут админок
спасибо, хорошее дополнение к посту.
 

Crazy Jack

Well-known member
08.07.2017
573
89
BIT
35
Интересно, что только сканер от IBM, в отличии от Acunetix, шарит что нужно грабить <!-- КОММЕНТАРИИ //-->
и таки при скане всего сайта дает годные результаты, например закоментированные, но активные формы ввода и загрузки,
годного результата я добился настройкой парсера Datacol под конкретный сайт, обход всего сайта, сбор комментариев, ну и по регуляркам все мыла, телефоны, содержимое <script>, ссылки, даже если они не очевидны и работают через JS, токены и прочее
Что за сканер от IBM?
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!