Исследование исходных кодов веб-страниц приложения.
При тестировании веб-приложений методом BlackBox у нас, как правило, не будет доступа ко всем исходным кодам приложения. Однако нам всегда доступен исходный код веб-страниц. Его необходимо тщательно изучить на предмет утечек информации.
Программисты, в том числе и разработчики веб-приложений, стараются комментировать свой код. Комментарии в коде полезны как во время разработки, так и после, особенно если разработчиков, работающих с данным кодом, много. Но комментарии в коде могут быть полезны и злоумышленникам, если они сожержат конфиденциальную информацию.
Кроме комментариев в коде стоит обратить внимание на теги <meta> (они так же могут содержать полезную информацию), скрипты (к примеру, можно обнаружить подозрительный код на сайте или определить технологии, которые используются в приложении), пути к ресурсам приложения. Ниже я приведу несколько примеров.
Теги <meta> с атрибутом name="author" позволяют тестеру определить автора документа, его email. Такая информация может помочь в дальшейшем при подборе паролей к административным интерфейсам или скорректировать векторы атаки:
Атрибут http-equiv тега <meta> позволяет изменять значения некоторых заголовков ответа веб-сервера. Браузер обрабатывает значение этого атрибута так, как будто бы это значение пришло непосредственно от сервера:
В данном случае в коде веб-страницы устанавливаются следующие заголовки ответа:
Refresh — с помощью этого значения определяется время задержки, после которой браузер автоматически перезагрузит страницу. Дополнительно в теге можно указать, какой именно документ нужно загрузить. В данном случае (на скрине выше) без какой-либо задержки должен загружаться документ /server-manager.
Expires - дата устаревания документа, при наступлении которой браузер должен обратиться к серверу за новой версией страницы, а не брать ее из кэша. Значение, равное нулю, интерпретируется как «сейчас».
Cache-Control определяет, должен ли браузер кэшировать данную страницу.
Иногда информация может быть раскрыта в коде скриптов:
в данном скрипте сожержится адрес, по которому, вероятно, находится тестовая версия приложения. При попытке доступа к странице по этому адресу запрашивается логин и пароль:
Так же по данному url мы можем предположить, что CMS тестируемого приложения — 1c-bitrix.
А в данном скрипте был раскрыт путь от сайта до корня сервера и один из ip-адресов:
Комментарии в js-скриптах или html-коде могут содержать учетные данные:
Непонятно, почему логин и пароль в таком виде и что это за кодировка. Но если посмотреть на длину логина и пароля, то можно предположить, что это 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-запрос, просмотр средствами браузера. Можно просмотреть как заголовки запроса и ответа, так и параметры запроса.
Заголовки ответа:
Заголовки запроса:
Параметры запроса:
Некоторые параметры в запросе выше являются скрытыми и их нельзя изменить через обычную форму ввода:
GET-запрос. В запросе имеется два параметра - параметр id со значением 69545 и параметр veaction со значением edit:
ЧПУ - человеко-понятные УРЛ, семантические URL
Человеко-понятный УРЛ - URL-путь, состоящий из понятных слов, вместо идентификаторов, и отражающий файловую структуру сайта. Например, вместо
Такие URL все чаще можно встретить в современных веб-приложениях. В связи с этим возникает вопрос, как определять параметры GET-запросов, если приложение использует ЧПУ?
Частично на данный вопрос отвечает этот документ -
Приведу один пример, в котором оказалось легко выявить параметры строки запроса. Ниже на скриншотах видим семантический URL:
и тот же запрос в привычном виде, с параметром и значением id=5:
Опять же можно попробовать поискать в Гугле. Такие проиндексированные URL могут дать некоторое понимание, как в приложении формируются запросы на самом деле:
Карта приложения.
Теперь, когда мы определили точки входа, для более ясного понимания структуры приложения, понимания его рабочих процессов, можно составить карту приложения. В ходе дальнейшего тестирования мы будем часто обращаться к этой карте, так как на ней будет наглядно представлено, какие части приложения мы уже протестировали, какие области еще не покрыты тестированием, в каких местах найдены уязвимости и недочеты.
Сбор информации для составления карты удобно выполнять с помощью OWASP Zap:
После того, как ZAP пройдется веб-пауком по всему сайту, можно выгрузить все найденные URL в отдельный текстовый файл. Структуру сайта и найденные точки входа можно просматривать в самом ZAP в навигационном окне слева. В окне справа можно просматривать каждый выполненый запрос и ответ.
Теперь на основе полученной информации можно составить карту. Я пробовал использовать для этого LibreOffice Draw и у меня получалось что-то вроде этого:
Реальная карта должна быть более детализирована. Чем выше детализация, тем лучше.
Но мне показалось удобнее составлять карту прямо в exel-таблице, в которой до этого я сохранял точки входа приложения, а так же запросы и ответы. Можно быстро вносить изменения в карту и делать пометки:
Как будете составлять карту вы, решайте сами, но хоть в каком-то виде она обязательно нужна.
Опытных пентестеров прошу поделиться в комментариях своими вариантами, если имеются.
У меня на сегодня все. Всем пока! )
При тестировании веб-приложений методом BlackBox у нас, как правило, не будет доступа ко всем исходным кодам приложения. Однако нам всегда доступен исходный код веб-страниц. Его необходимо тщательно изучить на предмет утечек информации.
Программисты, в том числе и разработчики веб-приложений, стараются комментировать свой код. Комментарии в коде полезны как во время разработки, так и после, особенно если разработчиков, работающих с данным кодом, много. Но комментарии в коде могут быть полезны и злоумышленникам, если они сожержат конфиденциальную информацию.
Комментарии HTML в коде начинаются с символов
Комментарии javascript бывают однострочные, и следуют за двойным слэшем
И бывают многострочные, которые заключаются между символами
<!-- и заканчиваются -->:<!-- это комментарий html -->Комментарии javascript бывают однострочные, и следуют за двойным слэшем
//// однострочный комментарий javascriptИ бывают многострочные, которые заключаются между символами
/* и */
Код:
/* это многострочный
комментарий */Кроме комментариев в коде стоит обратить внимание на теги <meta> (они так же могут содержать полезную информацию), скрипты (к примеру, можно обнаружить подозрительный код на сайте или определить технологии, которые используются в приложении), пути к ресурсам приложения. Ниже я приведу несколько примеров.
Теги <meta> с атрибутом name="author" позволяют тестеру определить автора документа, его email. Такая информация может помочь в дальшейшем при подборе паролей к административным интерфейсам или скорректировать векторы атаки:
Атрибут http-equiv тега <meta> позволяет изменять значения некоторых заголовков ответа веб-сервера. Браузер обрабатывает значение этого атрибута так, как будто бы это значение пришло непосредственно от сервера:
В данном случае в коде веб-страницы устанавливаются следующие заголовки ответа:
Refresh — с помощью этого значения определяется время задержки, после которой браузер автоматически перезагрузит страницу. Дополнительно в теге можно указать, какой именно документ нужно загрузить. В данном случае (на скрине выше) без какой-либо задержки должен загружаться документ /server-manager.
Expires - дата устаревания документа, при наступлении которой браузер должен обратиться к серверу за новой версией страницы, а не брать ее из кэша. Значение, равное нулю, интерпретируется как «сейчас».
Cache-Control определяет, должен ли браузер кэшировать данную страницу.
Иногда информация может быть раскрыта в коде скриптов:
в данном скрипте сожержится адрес, по которому, вероятно, находится тестовая версия приложения. При попытке доступа к странице по этому адресу запрашивается логин и пароль:
Так же по данному url мы можем предположить, что CMS тестируемого приложения — 1c-bitrix.
А в данном скрипте был раскрыт путь от сайта до корня сервера и один из ip-адресов:
Комментарии в js-скриптах или html-коде могут содержать учетные данные:
Непонятно, почему логин и пароль в таком виде и что это за кодировка. Но если посмотреть на длину логина и пароля, то можно предположить, что это 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-запрос, просмотр средствами браузера. Можно просмотреть как заголовки запроса и ответа, так и параметры запроса.
Заголовки ответа:
Заголовки запроса:
Параметры запроса:
Некоторые параметры в запросе выше являются скрытыми и их нельзя изменить через обычную форму ввода:
GET-запрос. В запросе имеется два параметра - параметр id со значением 69545 и параметр veaction со значением edit:
ЧПУ - человеко-понятные УРЛ, семантические URL
Человеко-понятный УРЛ - URL-путь, состоящий из понятных слов, вместо идентификаторов, и отражающий файловую структуру сайта. Например, вместо
/index.php?cat=10&subcat=2&id=41 будет /product/phone/Samsung/.Такие URL все чаще можно встретить в современных веб-приложениях. В связи с этим возникает вопрос, как определять параметры GET-запросов, если приложение использует ЧПУ?
Частично на данный вопрос отвечает этот документ -
Ссылка скрыта от гостей
.Приведу один пример, в котором оказалось легко выявить параметры строки запроса. Ниже на скриншотах видим семантический URL:
и тот же запрос в привычном виде, с параметром и значением id=5:
Опять же можно попробовать поискать в Гугле. Такие проиндексированные URL могут дать некоторое понимание, как в приложении формируются запросы на самом деле:
Карта приложения.
Теперь, когда мы определили точки входа, для более ясного понимания структуры приложения, понимания его рабочих процессов, можно составить карту приложения. В ходе дальнейшего тестирования мы будем часто обращаться к этой карте, так как на ней будет наглядно представлено, какие части приложения мы уже протестировали, какие области еще не покрыты тестированием, в каких местах найдены уязвимости и недочеты.
Сбор информации для составления карты удобно выполнять с помощью OWASP Zap:
После того, как ZAP пройдется веб-пауком по всему сайту, можно выгрузить все найденные URL в отдельный текстовый файл. Структуру сайта и найденные точки входа можно просматривать в самом ZAP в навигационном окне слева. В окне справа можно просматривать каждый выполненый запрос и ответ.
Теперь на основе полученной информации можно составить карту. Я пробовал использовать для этого LibreOffice Draw и у меня получалось что-то вроде этого:
Реальная карта должна быть более детализирована. Чем выше детализация, тем лучше.
Но мне показалось удобнее составлять карту прямо в exel-таблице, в которой до этого я сохранял точки входа приложения, а так же запросы и ответы. Можно быстро вносить изменения в карту и делать пометки:
Как будете составлять карту вы, решайте сами, но хоть в каком-то виде она обязательно нужна.
Опытных пентестеров прошу поделиться в комментариях своими вариантами, если имеются.
У меня на сегодня все. Всем пока! )
Последнее редактирование:
