Современные методы исследования безопасности веб-приложений: инструментарий

    image

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

    Большинство утилит содержится в популярных дистрибутивах тестирования на проникновение: Kali Linux, BlackArch, BackBox Linux. Для тех, у кого нет возможности по тем или иным причинам использовать эти дистрибутивы, я публикую ссылки на github/страницы утилит.

    Основные этапы


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

    Разведка


    Сканирование портов. На этом этапе поможет нестареющая классика — nmap. Для тех, кто столкнулся с этой утилитой впервые, необходимо учесть, что по умолчанию nmap сканирует ~1000 портов (первые и популярные выше), а также не сканирует UDP — имейте это в виду.

    Сканирование поддоменов. На этом этапе пригодится работа с утилитой dig и понимание AXFR запросов. Также пригодится утилита subbrute.

    Исследование видимого контента. Здесь, как не странно, вам пригодятся собственные глаза — для того чтобы визуально исследовать веб-приложение, понять его логику работы. Небольшой хинт: для того, чтобы сделать первоначальную проверку анонимной и не привлекать внимание, используйте кэш поисковых систем и системы типа google.tranlsate.

    Поиск скрытого контента (директорий, файлов, информации). На этом этапе пригодятся утилиты dirb, dirsearch, можно воспользоваться инструментами Foca (устарел) и maltego (необходима регистрация, есть платная версия).

    Определение платформы и веб-окружения. Здесь необходимо воспользоваться аддоном к браузеру wappalyzer или утилитой whatweb.

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

    Отдельно я бы хотел упомянуть «комбайны» для сбора информации: theharvester и recon-ng — с помощью этих инструментов можно получить довольно много информации — от выявления учетных записей и поддоменов до поиска критичной информации на сайте.

    Контроль доступа


    На данном этапе требуется как инструментальная, так и ручная проверка требований парольной политики.

    Для проверки необходимо провести атаку по словарю, например с помощью hydra или patator, используя заведомо известные учетные данные: таким образом можно выявить защиту от такого рода атак (или ее отсутствие).

    Определение требований парольной политики. Здесь ручная проверка логики требований политики. Использование только цифр (например как пин-кода) без защиты от брута — очень плохая идея.

    Тестирование восстановления учетной записи. На данном этапе приходится наличие нескольких ссылок или триггеров для сброса пароля (желательно от разных учетных записей). Здесь необходимо будет выявить и определить хеш (частое явление), например с помощью hashID. Далее необходимо произвести сравнение тригеров сброса (например ссылок) с помощью утилит сравнения (например comparer в burp suite).

    Тестирование функций сохранения сессии. Тестирование функций идентификации учетной записи. Проверка полномочий и прав доступа. Исследования сессии (время жизни, сессионный токены, признаки, попытки одновременной работы и т.д.) Проверка CSRF. Для этих задач хорошо подойдет mantra — есть версия как в виде firefox, так и chrome сборки.

    Фаззинг параметров


    Тестирование веб-приложения может быть выполнено как в инструментальном режиме (w3af, vega, arachni, sqlmap, Acunetix, Netsparker и.д.), так и полу-инструментальном — Burp Suite, OWASP ZAP и д.р.

    С помощью этих инструментов, как автоматическом, так и в ручном (наиболее точном) режиме можно выявлять следующие уязвимости: инъекции (SQL, SOAP, LDAP, XPATH и т.д.), XSS-уязвимости, редиректы и переадресации — весь спектр уязвимостей веба (OWASP TOP 10).

    Проверки логики работы веб-приложения


    Тестирование логики работы приложения на стороне клиента. Тестирование на т.н. «состояние гонки» — race condition. Тестирование доступности информации исходя из прав доступа или его отсутствия. Проверка возможности дублирования или разделения данных. На этом этапе нам понадобится хорошо изучить логику работы приложения и эксплуатация с помощью Burp Suite, OWASP ZAP или все той же mantra. Выявление таких уязвимостей в автоматическом режиме практически невозможно (кроме утилит работы с кодом для выявления формальных признаков такого рода уязвимостей и изучения исходного кода).

    Проверка серверного окружения


    Проверка архитектуры сервера. Поиск и выявление публичных уязвимостей. Проверка серверных учетных записей (службы и сервисы). Определение настроек сервера или компонентов (SSL и т.д.). Проверка прав доступа. Здесь можно воспользоваться как специализированными сканерами (под сервис), так и общеизвестными, например такими как OpenVAS, Armitage/Metasploit.

    Итого


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

    В комментариях буду рад ответить на ваши вопросы.
    • +22
    • 14,7k
    • 3
    Поделиться публикацией

    Комментарии 3

      0
      Ни один подобный список не может считаться полным. Ваш не повторяет даже OWASP Testing Checklist v4. Ещё и акцентирует внимание на автоматическом тестировании.
      –1
      Вторая статья, а я, как и в первой, не понимаю кому она адресована =)
      Слишком кратко. Про один nmap есть целая книга и одно только сканирование портов имеет гору нюансов, а вы отделались двумя предложениями. Про nmap знают почти все, а вот как правильно использовать «в бою» — вот это ценно узнать от опытного пентестера (а я смотрел ваш профиль).
      Но я позволю себе делать замечания.

      > Сканирование поддоменов. На этом этапе пригодится работа с утилитой dig и понимание AXFR запросов.
      Но трансфер зоны не имеет отношения к сканированию поддоменов. AXFR выдаст их на блюде и дальнейший поиск уже просто не нужен.
      Зато совсем не сказали, что найти поддомены можно:
      — в некоторых DNS записях — MX, TXT (spf)
      — в reverse-dns запросах
      — в TLS-сертификатах
      — в поисковиках общего назначения — google/yandex/yahoo
      — в специализированных поисковиках — shodan, censys, zoomeye, и тп
      ну и брутфорс, конечно, в основном интересен ссылками к словарям.
      Кстати, мне нравится для брута github.com/OJ/gobuster — все прелести Golang.

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

      Ага, только вы забыли сказать, что при просмотре кэша медиа контент (картинки и тп) — грузятся напрямую вашим браузером, а не с гугла. Поэтому ананомность так себе =)

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

      Либо здесь ошибка и имелся в виду этап «Исследование видимого контента», либо не затруднит ли вас пояснить, что подразумевается получать на этапе изучения скрытого контента и как там визуально изучать формы ввода?

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое