Как использовать OWASP Testing Guide v4

OWASP Testing Guide v4

Безопасность веба — очень широкое понятие. В него входят и недостатки старых протоколов, и использование каких-то опасных вещей, и просто человеческие ошибки, допущенные в процессе разработки софта. Очень непросто тестировать продукты в такой широкой области: для этого нужно придерживаться какого-то плана. И организация OWASP облегчила жизнь специалистам в области ИБ, создав OWASP Testing Guide.

Существует несколько наиболее распространенных методик пентеста, но конкретно для веба создана только вышеупомянутая. Про соответствие стандартам типа PCI DSS сейчас речь не идет, поскольку это узкоспециализированное направление, в статье же поговорим про универсальные методологии проведения тестирования. Что предлагает нам OWASP Testing Guide? Давай пробежимся по этому объемному документу и отметим его части, в которых тебя может ждать больше всего подводных камней. Это позволит составить представление о работе по данному руководству.

Если у тебя не получается освоить английскую версию гайда, то есть краудсорсинговый перевод, правда, недоделанный до конца. Кстати, у OWASP также есть методика для ревью исходного кода и для тестирования мобильных приложений. А с полным списком проектов ты можешь ознакомиться по ссылке https://owasp.org/projects.

Не так давно в «Хакере» вышла статья, раскрывающая основы тестирования сайтов на безопасность, в которой мельком говорится о методологии OWASP и об области ее применения. Текущая версия OWASP Testing Guide (PDF) имеет номер 4, пятая версия находится в стадии разработки (кстати, ты можешь делать коммиты в их публичном репозитории на GitHub). Но хоть руководство по тестированию довольно большое и, на первый взгляд, всеобъемлющее, его надо воспринимать как основу, а не как рецепт на все случаи жизни. В этой статье тебя ждет краткая инструкция по использованию 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-документами. Также надо быть готовым к ситуациям, не описанным в методологии, в том числе и к тому, что заказчик захочет протестировать свои системы защиты.

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

ВКонтакте
OK
Telegram
WhatsApp
Viber

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *