ANTICHAT - Раскройте Тайны Безопасности Веб-Приложений: Искусство Тестирования Исходного Кода

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

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

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

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

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

https://forum.antichat.xyz/attachmen...7a0ac7ac5f.png

https://forum.antichat.xyz/attachmen...a090148025.png

https://forum.antichat.xyz/attachmen...989f44bbdb.png

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

https://forum.antichat.xyz/attachmen...0c21634675.png

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

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

https://forum.antichat.xyz/attachmen...d38098dbe2.png

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

https://forum.antichat.xyz/attachmen...670a52cf03.png

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

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

https://forum.antichat.xyz/attachmen...34865fc5e4.png

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

https://forum.antichat.xyz/attachmen...c8e6a36a21.png

Непонятно, почему логин и пароль в таком виде и что это за кодировка. Но если посмотреть на длину логина и пароля, то можно предположить, что это 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-запрос, просмотр средствами браузера. Можно просмотреть как заголовки запроса и ответа, так и параметры запроса.
Заголовки ответа:

https://forum.antichat.xyz/attachments/4848124/14.png

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

https://forum.antichat.xyz/attachments/4848124/16.png

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

https://forum.antichat.xyz/attachments/4848124/15.png

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

https://forum.antichat.xyz/attachments/4848124/16.png

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

https://forum.antichat.xyz/attachments/4848124/13.png

ЧПУ - человеко-понятные УРЛ, семантические URL
Человеко-понятный УРЛ - URL-путь, состоящий из понятных слов, вместо идентификаторов, и отражающий файловую структуру сайта. Например, вместо

Код:

/index.php?cat=10&subcat=2&id=41

будет

Код:

/product/phone/Samsung/

.
Такие URL все чаще можно встретить в современных веб-приложениях. В связи с этим возникает вопрос, как определять параметры GET-запросов, если приложение использует ЧПУ?
Частично на данный вопрос отвечает этот документ - https://www.ptsecurity.com/upload/corporate/ru-ru/analytics/ModrewriteFuzzing-rus.pdf.

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

https://forum.antichat.xyz/attachments/4848124/11.png

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

https://forum.antichat.xyz/attachmen...6a0b13a359.png

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

https://forum.antichat.xyz/attachmen...4b44a4bef2.png

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

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

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

https://forum.antichat.xyz/attachmen...a739a707cd.png

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

https://forum.antichat.xyz/attachmen...3c02e76687.png

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

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

https://forum.antichat.xyz/attachmen...6d90caa9e0.png

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

У меня на сегодня все. Всем пока! )