ANTICHAT — форум по информационной безопасности, OSINT и технологиям

Привет, античат !

В прошлой статье я рассмотрел общий подход к тестированию веб-приложений, основаный на OWASP Testing Guide.
Сегодня получим еще небольшую дозу теории и уже приступим к практической части.
Считайте этот текст вольным и адаптированным (под меня)) переводом данного руководства.

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

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

Иными словами, если перед нами на первый взгляд три абсолютно одинаковых интернет-магазина на OpenCart, это не значит, что они одинаковы на самом деле. Может быть один из них крутится на веб-сервере apache, второй на nginx, а третий тоже на nginx, но использует не MySQL, как первые два, а PostgreSQL. Суть, думаю, ясна.

Цель проекта OWASP Testing Guide — собрать все возможные методы тестирования, объяснить их и постоянно обновлять руководство. Метод тестирования основан на подходе Black Box или Черный Ящик, когда тестеру ничего заранее неизвестно о тестируемом приложении или известно очень мало.

Тестирование делится на два этапа:
Пассивный режим — когда тестер пытается понять логику приложения и играет с ним. Могут быть использованы инструменты для сбора информации, например http-прокси для мониторинга всех http-запросов и ответов. В конце этого этапа тестер должен выявить все точки входа приложения (http-заголовки, параметры, cookie).

Например, пентестер может обнаружить такой URL:

Он может указывать на форму аутентификации, где пользователь должен ввести логин и пароль.

Следующий URL представляет две точки входа приложения:

Тут мы имеем два параметра, параметр a и параметр b, посредством которых передаются пользовательские данные.
Обнаружив все точки входа, запишите их в таблицу. Они будут нужны на втором, активном этапе тестирования.

Активный режим — в ходе которого тестер должен собрать информацию о приложении, протестировать конфигурацию, управление идентификацией, аутентификацию, авторизацию, входные данные, бизнес-логику и так далее.

Используйте чек-лист в ходе тестирования, что бы ничего не забыть и не пропустить.

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

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

Допустим, вы владелец интернет-магазина. Изначально мета-теги и robots.txt были настроены правильно и ничего лишнего в выдачу поисковиков не попало. Потом вы решили изменить или добавить новый функционал к магазину. Суть его в том, что зарегистрированный покупатель из своего личного кабинета может просмотреть информацию о своих прошлых покупках, такую как дата заказа, наименование товара, адрес доставки, номер телефона покупателя, способ платежа и так далее, то есть то, что не должны видеть посторонние люди и тем более это не должно попасть в выдачу поисковиков. Но вот правильно настроить магазин после этого забыли. Результат может быть таким, как на скриншотах ниже:

Пример 1.



Пример 2.



Тот факт, что такие веб-страницы в принципе доступны для просмотра неаутентифицированным юзерам — тема другого раздела, до которого нам еще далеко. Но то, что они оказались в выдаче гугла — это результат неправильной настройки robots.txt и тегов meta в html-страницах.

Вообразим другую ситуацию. Вы решили обновить свой сайт, а старую версию сайта временно разместили по адресу old.mysite.ru. Через какое-то время старую версию вы удалили окончательно, и больше не переживаете за нее, а зря и вот почему:

Пример 3.



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

Мы использовали прямой метод получения информации о цели. А что же с косвенным?
Представьте, что разработчики вашего интернет-магазина для удобства использовали какой-нибудь git-репозиторий, на который они выложили весь исходный код магазина и по какой-то причине, уже не зависящей от вас, репозиторий был проиндексирован поисковиком. Таким образом в руках злоумышленника может оказать информация о структуре вашего сайта, что сильно поможет ему при дальнейшем поиске уязвимостей.
Так же в поиске нужной информации вам могут помочь приожения, которые делают архивные копии сайтов со всего интернета, к примеруhttps://web.archive.org/.

Рассмотрим еще один кейс с примером. Мы тестируем сайт, о владельцах которого нам известно мало или неизвестно ничего. На сайте находим такую информацию:

Пример 4.



UK Registered Company Number — меня заинтересовал этот идентификатор. Не знаю, что это, наверное что-то типа нашего ИНН. После быстрого гугления находим сайт, на котором по данному номеру можно получить некоторые данные о компании и владельцах:

Пример 5.



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

Ищите и обрящете. Мало ли, что попадет в гугл и как это "что" вам поможет далее.





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

Изучите и используйте специальные операторы поисковых систем, которые будете использовать при тестировании. Вот, например, хорошаястатья на Хабре про поисковые операторы Гугла. Не ограничивайтесь Гуглом, поскольку другие поисковые системы могут выдавать другие результаты поиска. Рассмотрите возможность использования следующих поисковых систем:

Baidu
binsearch.info
Bing
Duck Duck Go
ixquick/Startpage
Google
Yandex
Shodan

DuckDuckGo и ixquick/Startpage обеспечивают некоторую анонимность для пентестера. Shodan выполняет поиск по устройствам или как говорят сегодня, поисковик по интернету вещей. Google имеет полезный оператор «cashe:».
В этом списке должен еще быть поисковик PunkSpider, но у меня он почему-то ни разу не открылся.

В ходе поиска задействуйте свою фантазию и терпение и тогда вам обязательно повезет