- PVSM.RU - https://www.pvsm.ru -
Сегодня у нас не совсем обычная статья. Как следует из заголовка, она посвящена проблемам непрерывной защиты веб-приложений и разбита на две части, отражающие два взгляда на проблему: с позиции разработчиков WAF (Андрей Петухов, SolidLab) и с точки зрения центра мониторинга и противодействия кибератакам, который использует WAF для оказания сервиса клиентам (@avpavlov, Solar JSOC).
Начнем мы с разработчиков, а через неделю дадим слово эксплуатантам WAF.
Мы из SolidLab. Наша основная экспертиза – это application security во всех проявлениях – offensive (анализ защищенности приложений, инфраструктур, процессов) и defensive (построение SDLC и отдельные аспекты этого – например, ручной анализ кода, обучающие курсы и семинары, внедрение средств защиты вообще и нашего WAF в частности).
Для начала мы хотели бы поговорить о тенденциях в мире разработки и эксплуатации веб-приложений, которые определяют ландшафт угроз и методы защиты. Полагаем, что рассуждения о SOC, непрерывном мониторинге и WAF’ах скоро будут неотделимы от рассуждений о непрерывной разработке и особенностях этого процесса для того или иного приложения/сервиса. Начнем с очевидной тенденции к сокращению длительности релизного цикла. Интересные факты:
Короткие релизные циклы приводят к переосмыслению причин и мотивов, которые делали целесообразным использование традиционных мероприятий – привлечение внешних консультантов для поиска недостатков (неважно, каким методом – «белым» или «черным» ящиком), ручное тестирование собственной QA- или security-командой: схема «проверил код релиза и живи полгода спокойно до следующего» больше не работает. В разработке с короткими релизными циклами перечисленные «традиционные» мероприятия рассматриваются уже более зрело: как источник обратной связи на процессы и их обеспечение всем необходимым – инструментами, людьми, методиками, а не как способ получить некоторое защищенное состояние приложения и зафиксировать его.
Отметим, что непрерывность процессов (особенно в части тестирования и развертывания) подразумевает переход к высокой степени автоматизации рутинных задач. Автоматизация отлично помогает снизить частоту попадания в продукт типичных (понятных для всех участников разработки) недостатков:
Тут же заметим, что решение рутинных задач современные веб-платформы и фреймворки (RoR, Django, Spring, Struts, ASP.NET MVC и т.п.) стараются забирать на себя, не давая шанса разработчикам выстрелить себе в ногу, реализовав, например, собственную защиту от CSRF или шаблонизатор на основе find/replace. Соответственно, по мере адаптации новых веб-платформ в перспективе можно ожидать снижение вероятности привнесения в код недостатков, позволяющих проводить атаки типа CSRF, SQL injection, XSS. Что уж говорить, даже большинство XML-парсеров сегодня по умолчанию запрещают разрешение внешних сущностей (т.е. применяют принцип safe defaults).
Не такой прямолинейной с идейной точки зрения оказывается тактика борьбы с недостатками других типов:
Для полноты изложения важно упомянуть о вариантах решения перечисленных задач в рамках sSDLC методами, альтернативными от мониторинга.
От нетипичных недостатков можно избавляться через whateverbox-анализ от сторонней организации, проводимый с определенной периодичностью, или через массовое народное непрерывное тестирование aka Bug Bounty. Недостатки третьего типа на этапе сборки можно устранять, реализовав анализ внешних зависимостей (см. Vulners, WhiteSource, OWASP dependency-check), а на этапе эксплуатации – выполнением тех же проверок теми же инструментами, но в виде отдельного задания и с большей частотой. Мы же с коллегами больше будем говорить про защиту от атак через непрерывный мониторинг и реагирование.
С точки зрения управления процессом разработки параметры защищенности создаваемого ПО/сервиса – целевые показатели, подлежащие планированию. Тактика достижения этих показателей, по-хорошему, определяется на этапе инициализации проекта (или на этапе его реформирования) и зависит от модели угроз и оценки рисков, ограничений (бюджетных, временных и других), доступных производственных ресурсов (квалификация, методическое обеспечение) и так далее. Наше видение заключается в том, что правильно организованный мониторинг веб-приложения на этапе эксплуатации обеспечит не только снижение рисков, связанных с реализацией угроз через недостатки веб-приложения и его окружение (что очевидно), но и снижение рисков, связанных с неправильными управленческими решениями, которые принимаются в процессе разработки, или ненадлежащей реализацией хороших и правильных решений.
Другими словами, наличие правильного мониторинга увеличивает число степеней свободы при определении тактики достижения параметров защищенности создаваемого ПО/сервиса на начальном этапе.
Из рассуждений выше видно, что среди прочих, правильный мониторинг должен решать следующие ключевые задачи защиты веб-приложений:
Помимо перечисленных задач, которые, по нашему мнению, должны решаться правильным мониторингом (и любым WAF’ом как основным инструментом для построения такого процесса), мы еще предлагаем список архиважных фич для WAF'ов.
В отличие от задачи сравнения WAF’ов вообще (по функциональным критериям или критериям производительности) и разговоре об эффективности вообще (еще не один benchmark WAF’ов не был признан сообществом, все были прилично раскритикованы), мы хотим обратить внимание на свойства инструментов, которые позволят оценить, подходит ли данный инструмент для защиты конкретного приложения. Постановка задачи именно такая – оценить применимость WAF для конкретного приложения на конкретном стеке технологий.
WAF должен понимать прикладной протокол защищаемого приложения
Здесь действует простое правило: если WAF не сможет разобрать, каким образом передаются значения параметров, он не сможет обнаружить и манипуляции с этими значениями (injection/tampering).
Под прикладным протоколом приложения мы понимаем:
Таким образом, разбор протокола защищаемого приложения WAF’ом – это определение по каждому HTTP-запросу, какая функция приложения вызывается или какой ресурс запрашивается, с какими параметрами и от чьего имени, если речь идет о закрытой зоне приложения, доступной после аутентификации.
В качестве примера интересных протоколов передачи параметров можно привести следующие:
Соответственно, если WAF не может получить из запроса конечные значения параметров, с которыми оперирует защищаемое приложение, то WAF не работает. Отметим, что существует приличное количество способов сериализации бинарных объектов (а еще можно запилить свой собственный!).
http://apex.app:8090/apex/f?p=30:180:3426793174520701::::P180_ARTICLE_ID:5024
POST-запросы в URL-части – аналогично, а параметры передаются в теле (x-www-urlencoded), но названия вне зависимости от вызываемой операции – одинаковые: x01=val1&x02=val2… и т.п. Вот пример запроса:
Если в первых двух примерах разбор протокола требовался для определения значений входных параметров, то в приложениях такого типа WAF дополнительно должен понять, какая запрашивается операция или ресурс. Заметим, что никто не мешает разработчикам приложений на APEX в параметрах x01, x02,… передавать, например, XML/JSON, закодированный в base64, или, как на последнем снимке, сериализованные X-WWW-URLENCODED параметры.
WAF должен иметь гранулярность уровня операций защищаемого приложения
Приложения на APEX отлично иллюстрируют следующий тезис: WAF должен применять свои механизмы/политики/правила не с гранулярностью сущностей HTTP-протокола (секции URL, заголовки и их значения, имена параметров и их значения), а с гранулярностью функций приложения и их входных параметров.
Действительно, для приложения на APEX параметры x01, x02 и т.п. будут являться транспортом значений для всех его функций, но:
Получается, что от механизмов WAF мы хотим следующего:
Авторы данной статьи встречались с ситуацией, когда на WAF одного крупного вендора не работал User Tracking[1] [1] на APEX-приложении как раз из-за того, что правила для разделения успешного login-действия, неуспешного login-действия, logout-действия и остальных действий невозможно было задать предоставляемыми выразительными средствами — это были регулярные выражения над полями HTTP-запроса.
Приведенные рассуждения справедливы, конечно, не только для APEX-приложений, но и для различных приложений со сложной маршрутизацией не на основе URL: XML-RPC, JSON-RPC, SOAP и т.п.
WAF должен иметь возможность задания политик на уровне операций и объектов защищаемого приложения
Не секрет, что основными способами обнаружения атак на веб-приложения являются синтаксический анализ для обнаружения синтаксических аномалий (соответствует injection-атакам) и статистический анализ для обнаружения аномалий, связанных со слишком большим количеством запросов (подбор паролей/токенов/OTP, дирбастинг, перечисление объектов приложения – например, существующих пользователей, умный DoS и так далее). Намного сложнее ловятся атаки, которые не вызывают синтаксических или статистических аномалий – типичным примером будет запрос чужих объектов (англ. Insecure Direct Object Reference). Такие атаки часто еще называют «логическими» или атаками на бизнес-логику.
Возникает справедливый вопрос – на каком уровне абстракции происходят аномалии при атаках такого типа?
Мы считаем, что аномалии, возникающие при атаках на бизнес-логику – это аномалии уровня операций и объектов защищаемого приложения, для чего требуется понимать сценарии использования приложения, жизненный цикл и принадлежность его объектов пользователям приложения, вычислять зависимости по данным и по объектам между отдельными шагами одного сценария использования или между различными сценариями использования, можно выявить аномалии, возникающие при атаках на уровне логики.
На наш взгляд, перспективой развития WAF’ов как инструментов мониторинга является именно понимание уровня предметной области приложений, работа на уровне операций и объектов, построение между ними зависимостей и, как следствие, обнаружение атак на логику сценариев в этой предметной области.
Автор: SolarSecurity
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/259530
Ссылки в тексте:
[1] [1]: #rlink
[2] Источник: https://habrahabr.ru/post/331786/
Нажмите здесь для печати.