Безопасность веба — очень широкое понятие. В него входят и недостатки старых протоколов, и использование каких-то опасных вещей, и просто человеческие ошибки, допущенные в процессе разработки софта. Очень непросто тестировать продукты в такой широкой области: для этого нужно придерживаться какого-то плана. И организация OWASP облегчила жизнь специалистам в области ИБ, создав OWASP Testing Guide. Существует несколько наиболее распространенных методик пентеста, но конкретно для веба создана только вышеупомянутая. Про соответствие стандартам типа PCI DSS сейчас речь не идет, поскольку это узкоспециализированное направление, в статье же поговорим про универсальные методологии проведения тестирования. Что предлагает нам OWASP Testing Guide? Давай пробежимся по этому объемному документу и отметим его части, в которых тебя может ждать больше всего подводных камней. Это позволит составить представление о работе по данному руководству. WWW Если у тебя не получается освоить английскую версию гайда, то есть краудсорсинговый перевод, правда, недоделанный до конца. Кстати, у OWASP также есть методика для ревью исходного кода и для тестирования мобильных приложений. А с полным списком проектов ты можешь ознакомиться по ссылке https://owasp.org/projects. Не так давно в «Хакере» вышла статья, раскрывающая основы тестирования сайтов на безопасность, в которой мельком говорится о методологии OWASP и об области ее применения. Текущая версия OWASP Testing Guide (PDF) имеет номер 4, пятая версия находится в стадии разработки (кстати, ты можешь делать коммиты в их публичном репозитории на GitHub). Но хоть руководство по тестированию довольно большое и, на первый взгляд, всеобъемлющее, его надо воспринимать как основу, а не как рецепт на все случаи жизни. В этой статье тебя ждет краткая инструкция по использованию OWASP Testing Guide. Не все то золото, что блестит Как говорил Эйнштейн, «порядок необходим глупцам, а гений властвует над хаосом». Но в тестировании четкое планирование — это синоним успеха. Тем не менее, план обычно описывает лишь приблизительную последовательность действий, даже если он очень детализирован. Предусмотреть все возможные ситуации зачастую нереально. И дело не только в том, что новые технологии появляются с гораздо большей скоростью, чем обновляется методика, но и в том, что веб-приложения могут использоваться для чего угодно: от создания простого сайта-визитки до панели администратора, с помощью которой можно управлять физическими устройствами. Поэтому подобные методологии стоит использовать только в качестве фундамента и думать своей головой, при этом не забывая дополнять существующий план практическим опытом. Следует использовать все доступные и подходящие инструменты. Во-первых, во время тестирования по одному разделу инструменты могут давать разные результаты, а во-вторых, наложение части разделов на другие поможет закрыть потенциальные недочеты, ранее не выявленные тестировщиком или автоматическим инструментарием. Также может сложиться впечатление, что методика больше предназначена для Black Box тестирования (несмотря на сноски Gray Box и White Box в самом тексте), но, в принципе, ее можно распространить на любой вид тестирования, добавив соответствующие методы и связанные с ними инструменты. 0. Testing Guide Introduction В начале руководства по тестированию от OWASP есть небольшое предисловие, гласящее, что автоматизированное Black Box тестирование имеет недостатки и его надо дополнять ручным тестированием. Это так, однако в самом тексте гайда встречаются различные примеры использования сканера Nessus, но нет ни слова про сканер OpenVas, который, в принципе, не сильно хуже. Имеет смысл использовать все имеющиеся сканеры и другие фичи платных продуктов (например, burp pro), поскольку разные инструменты могут дать разные результаты. Не пренебрегай и ложноположительными срабатываниями, поскольку такие результаты иногда внезапно оказываются истинными. 1. Testing for Information Gathering 1.1 Conduct search engine discovery/reconnaissance for information leakage Сбор информации из открытых источников (OSINT) — первый этап любого пентеста, в том числе, и пентеста веб-приложения. Этот этап проводится еще до начала работ, чтобы проверить, действительно ли тестируемые объекты принадлежат заказчику, или чтобы оценить примерный объем работ для оценки трудозатрат.