Безопасность веба — очень широкое понятие. В него входят и недостатки старых протоколов, и использование каких-то опасных вещей, и просто человеческие ошибки, допущенные в процессе разработки софта. Очень непросто тестировать продукты в такой широкой области: для этого нужно придерживаться какого-то плана. И организация OWASP облегчила жизнь специалистам в области ИБ, создав OWASP Testing Guide.
Существует несколько наиболее распространенных методик пентеста, но конкретно для веба создана только вышеупомянутая. Про соответствие стандартам типа PCI DSS сейчас речь не идет, поскольку это узкоспециализированное направление, в статье же поговорим про универсальные методологии проведения тестирования. Что предлагает нам OWASP Testing Guide? Давайте пробежимся по этому объемному документу и отметим его части, в которых вас может ждать больше всего подводных камней. Это позволит составить представление о работе по данному руководству.
Как использовать OWASP Testing Guide v4
Как говорил Эйнштейн, «порядок необходим глупцам, а гений властвует над хаосом». Но в тестировании четкое планирование — это синоним успеха. Тем не менее, план обычно описывает лишь приблизительную последовательность действий, даже если он очень детализирован. Предусмотреть все возможные ситуации зачастую нереально.
И дело не только в том, что новые технологии появляются с гораздо большей скоростью, чем обновляется методика, но и в том, что веб-приложения могут использоваться для чего угодно: от создания простого сайта-визитки до панели администратора, с помощью которой можно управлять физическими устройствами. Поэтому подобные методологии стоит использовать только в качестве фундамента и думать своей головой, при этом не забывая дополнять существующий план практическим опытом.
Следует использовать все доступные и подходящие инструменты. Во-первых, во время тестирования по одному разделу инструменты могут давать разные результаты, а во-вторых, наложение части разделов на другие поможет закрыть потенциальные недочеты, ранее не выявленные тестировщиком или автоматическим инструментарием.
Также может сложиться впечатление, что методика больше предназначена для 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) — первый этап любого пентеста, в том числе, и пентеста веб-приложения. Этот этап проводится еще до начала работ, чтобы проверить, действительно ли тестируемые объекты принадлежат заказчику, или чтобы оценить примерный объем работ для оценки трудозатрат.
В методологии этот этап в основном строится на использовании поисковых движков (причем разных, чтобы скомпенсировать ограничения одного преимуществами другого). Здесь вам на помощь придет статья, описывающая возможности DuckDuckGo, заметка про операторы поиска и google dorks.
Но, разумеется OSINT не ограничивается только лишь использованием поиска, как минимум из-за наличия неиндексируемых форумов, в том числе, в даркнете, или персонализированной выдачи. Поиграться с ней поможет вот этот сайт. Кстати, на любом этапе тестирования не стоит забывать о персонализированной выдаче самого тестируемого ресурса.
К слову, недавно появился форк Sherlock’а для поиска по СНГ. Можно использовать разные техники пассивного сбора информации, в том числе, такой инструмент, как FOCA для получения метаданных из документов, которые скорее всего присутствуют на тестируемых ресурсах.
Не стоит забывать про сайты, прямо или косвенно связанные с IT, а также тематические (относительно тематики тестируемого объекта) ресурсы. В общем, про OSINT можно говорить долго, суть в том, что надо использовать руководство по тестированию, как основу, а не как пошаговую инструкцию.
1.4 Enumerate applications on webserver
В этом разделе речь идет о различных веб-приложениях, доступных либо по секретным субдоменам, либо по относительным путям, к которым имеется доступ извне. Имеются в виду некие ресурсы сайта, куда может проникнуть лишь тот, кто знает их URL, по понятным причинам нигде не афишируемый. Раздел можно дополнить следующими трюками:
- сайты могут быть похожи друг на друга (например, их делал один подрядчик). Можно использовать инструмент для поиска идентичных фрагментов кода (комментарии, разные идентификаторы в JS-библиотеках, имена авторов в комментариях и т.д.) наподобие https://publicwww.com/ в надежде, что эти сайты были проиндексированы;
- можно использовать разные инструменты для поиска субдоменов, или искать их самому вручную, используя поиск по сертификатам или DNS-запросы. Можно использовать свои или общедоступные словари для перебора, ну и в целом задействовать разные инструменты, поскольку они постоянно обновляются и совершенствуются.
1.7 Map execution paths through application
Здесь говорится о составлении «карты» веб-приложения, то есть, об отображении в текстовом или графическом виде всех или почти всех разделов сайта. Если этот процесс автоматизировать с помощью соответствующих инструментов, то вы получите схему веб-приложения или сайта, на которую можно опираться при тестировании. Например, такая схема поможет классифицировать рубрики сайта по разделам методологии. К тому же, автоматизированные утилиты могут обнаружить то, что вы упустили на этапе сбора информации.
2. Configuration and Deployment Management Testing
В этом разделе описано тестирование инфраструктуры веб-приложения. В гайде речь идет в основном о веб-сервере и СУБД. И хоть это фундамент любого веб-приложения, не стоит забывать про CI/CD-системы, шины сообщений и прочие компоненты инфраструктуры. Конечно, если они входят в намеченный план работ.
4/5. Authentication testing/Authorization testing
При тестировании аутентификации и авторизации не стоит забывать про такие вещи, как OAuth, SSO, OpenID. Вам даже может встретиться аутентификация по сертификатам.
В общем, не теряйтесь, когда на горизонте появится что-то подобное, ведь схем аутентификации и авторизации существует множество. Сразу все не изучить, и практика их эксплуатации на реальных проектах появится не сразу: главное понять, к какому разделу тестирования это относится.
7. Input validation testing
Первые два пункта этого раздела связаны с reflected/stored XSS-уязвимостями. Но XSS-уязвимости являются подклассом более общих уязвимостей — reflected/stored HTML injection. Может случиться так, что XSS нет, а вот HTML injection есть. Кстати, помимо XSS/HTML-инъекций также не забывайте про инъекции в шаблоны — довольно серьезный подкласс атак, который может привести к удаленному исполнению кода. Еще одним подвидом атаки удаленного исполнения кода является атака SSRF.
Также не стоит забывать о том, в каком окружении работает веб-приложение. Нужно подумать о том, как потенциальный злоумышленник может использовать это для своей выгоды. Вот пример утечки хешей с Winodws-сервера из-за одной лишь уязвимости недостаточно хорошей фильтрации вводимых данных.
В 7 разделе также говорится про бинарные уязвимости Overflow и Format String: сюда вообще стоит включить весь спектр бинарных уязвимостей со всевозможными ухищрениями, которые можно осуществить удаленно. Это тема для отдельной статьи или даже книги, и еще одно подтверждение тому, что в области ИБ надо развиваться всесторонне.
10. Business logic testing
Вообще, в раздел, посвященный тестированию бизнес логики, можно включить все, что угодно. Проблемы в этой сфере могут привести к возможности DDOS-атаки, нарушению целостности, конфиденциальности и доступности информации, и т.д. Вариантов можно придумать уйму, тут суть не в том, чтобы предусмотреть все возможные варианты, а в том, чтобы научиться действовать по ситуации. Потому этот раздел носит в основном теоретический характер: практические приемы тестирования зависят от архитектуры и внутреннего устройства конкретного исследуемого объекта.
11. Client side testing
В первых двух пунктах этой части руководства речь снова заходит об XSS-уязвимостях, но на стороне клиента. Тут следует обратить внимание на два обстоятельства. Во-первых, не стоит забывать про HTML injection (ее тоже можно осуществить на стороне клиента). Во-вторых, XSS-уязвимости делятся на 4 типа:
- server-side reflected
- server-side stored
- client-side reflected
- client-side stored
В последнем случае в качестве хранилища для XSS-нагрузки используется хранилище браузера (в пределах сессии или же на более долгий срок). На мой взгляд, деление должно быть именно по client-side reflected и client-side stored, ибо атаки DOM-based XSS и arbitrary JS injections могут быть выполнены в контексте обеих вышеупомянутых уязвимостей.
Аналогично, родственником атаки SSTI (server side template injection) является CSTI. Принцип ее тот же самый, но осуществляется она на стороне клиента.
Заключение
Веб-технологии имеют разные (иногда неочевидные) нюансы, и держать все это в голове просто невозможно, даже при наличии опыта. Главное оружие пентестера — это поисковые системы ваш личный набор инструментов.
А опыт приходит с практикой. Теоретические же знания можно почерпнуть в книгах, форумах, статьях, репортах на багбаунти-площадках. Можно даже вести свою собственную базу знаний — это особенно удобно, если вы посещаете выступления на различных конференциях вроде PHDays, ZeroNights, RuCTF, OffensiveCon и других, или просматриваете видеолекции. А методология по тестированию в каждом новом проекте — это лишь отправная точка для дальнейшей работы.
Стоит гуглить все, что связано с безопасностью того компонента, который используется в веб-приложении. Например, JWT по отношению к JAVA, Web Services, если вы встретились с SOAP, или XXE и XSLT, если нужно разобраться с XML-документами. Также надо быть готовым к ситуациям, не описанным в методологии, в том числе и к тому, что заказчик захочет протестировать свои системы защиты.
Не забывайте о необходимости творчески подходить к процессу: даже очень подробный гайд все равно не предусмотрит всех возможных ситуаций. Дополнительно для систематизации собственных знаний можно изучить разные классификации угроз безопасности.
