информационная безопасность web приложений
Безопасность веб-приложений: от уязвимостей до мониторинга
Уязвимости веб-приложений возникают тогда, когда разработчики добавляют небезопасный код в веб-приложение. Это может происходить как на этапе разработки, так и на этапе доработки или исправления найденных ранее уязвимостей. Недостатки часто классифицируются по степени критичности и их распространенности. Объективной и наиболее популярной классификацией уязвимостей считается OWASP Top 10. Рейтинг составляется специалистами OWASP Project и актуализируется каждые 3-4 года. Текущий релиз выпущен в 2017 году, а следующий ожидается в 2020-2021.
Распространенные уязвимости
Для начала рассмотрим типовые уязвимости, которым подвержены многие веб-приложения.
Инъекции
Как и полагается, атаки класса «Инъекции» занимают лидирующую строчку рейтинга OWASP Top 10, встречаясь практически повсеместно и являясь крайне разнообразными в реализации. Уязвимости подобного класса начинаются SQL-инъекциями, в различных его вариациях, и заканчивая RCE — удаленным выполнением кода.
Межсайтовый скриптинг — уязвимость, встречающаяся на данный момент куда реже, чем раньше, если верить рейтингу OWASP Top 10, но несмотря на это не стала менее опасной для веб-приложений и пользователей. Особенно для пользователей, ведь атака XSS нацелена именно на них. В общем случае злоумышленник внедряет скрипт в веб-приложение, который срабатывает для каждого пользователя, посетившего вредоносную страницу.
LFI/RFI
Уязвимости данного класса позволяют злоумышленникам через браузер включать локальные и удаленные файлы на сервере в ответ от веб-приложения. Эта брешь присутствует там, где отсутствует корректная обработка входных данных, которой может манипулировать злоумышленник, инжектировать символы типа path traversal и включать другие файлы с веб-сервера.
Атаки через JSON и XML
Веб-приложения и API, обрабатывающие запросы в формате JSON или XML, также подвержены атакам, поскольку такие форматы имеют свои недостатки.
JSON (JavaScript Object Notation) — это облегченный формат обмена данными, используемый для связи между приложениями. Он похож на XML, но проще и лучше подходит для обработки с помощью JavaScript. Многие веб-приложения используют этот формат для обмена данными между собой и сериализации/десериализации данных. Некоторые веб-приложения также используют JSON для хранения важной информации, например, данных пользователя. Обычно используется в RESTful API и приложениях AJAX.
JSON чаще всего ассоциируется с API, тем не менее, часто используется даже в обычных и хорошо известных веб-приложениях. Например, редактирование материалов в WordPress производится именно через отправку запросов в формате JSON:
JSON Injection
Простая инъекция JSON на стороне сервера может быть выполнена в PHP следующим образом:
Простая инъекция JSON на стороне клиента может быть выполнена следующим образом:
JSON Hijacking
Захват JSON — атака, в некотором смысле похожая на подделку межсайтовых запросов (CSRF), при которой злоумышленник старается перехватить данные JSON, отправленные веб-приложению с веб-сервера:
XML External Entity
Атака внешней сущности XML (XXE) — это тип атаки, в котором используется широко доступная, но редко используемая функция синтаксических анализаторов XML. Используя XXE, злоумышленник может вызвать отказ в обслуживании (DoS), а также получить доступ к локальному и удаленному контенту и службам. XXE может использоваться для выполнения подделки запросов на стороне сервера (SSRF), заставляя веб-приложение выполнять запросы к другим приложениям. В некоторых случаях c помощью XXE может даже выполнить сканирование портов и удаленное выполнение кода.
XML (Extensible Markup Language) — очень популярный формат данных. Он используется во всем: от веб-сервисов (XML-RPC, SOAP, REST) до документов (XML, HTML, DOCX) и файлов изображений (данные SVG, EXIF). Для интерпретации данных XML приложению требуется анализатор XML, известный как XML-процессор. XML можно использовать не только для объявления элементов, атрибутов и текста. XML-документы могут быть определенного типа. Тип указывается в самом документе, объявляя определение типа. Анализатор XML проверяет, соответствует ли XML-документ указанному типу, прежде чем обрабатывать документ. Вы можете использовать два варианта определений типов: определение схемы XML (XSD) или определение типа документа (DTD). Уязвимости XXE встречаются в последнем варианте. Хотя DTD можно считать устаревшими, но он все еще широко используются.
Фактически, объекты XML могут поступать практически откуда угодно, включая внешние источники (отсюда и название XML External Entity). При этом, XXE может стать разновидностью атаки подделки запросов на стороне сервера (SSRF). Злоумышленник может создать запрос, используя URI (известный в XML как системный идентификатор). Если синтаксический анализатор XML настроен для обработки внешних сущностей, а по умолчанию многие популярные анализаторы XML на это настроены, веб-сервер вернет содержимое файла в системе, потенциально содержащего конфиденциальные данные.
Злоумышленник, разумеется, не ограничивается системными файлами. Можно легко заполучить и другие локальные файлы, включая исходный код, если известно расположение файлов на сервере или структура веб-приложения. Атаки на внешние объекты XML могут позволить злоумышленнику выполнять HTTP-запросы к файлам в локальной сети т.е. доступным только из-за брандмауэра.
Веб-приложения — неотъемлемая часть рабочего процесса большинства организаций — АБС системы банков, CRM, 1C и другие программы, которыми ежедневно пользуются сотрудники. Они аккумулируют в себе огромное количество данных, обладающих коммерческой ценностью. Поэтому способствовать обеспечению безопасности веб-приложений — одна из ключевых задач для минимизации финансовых и репутационных рисков бизнеса.
Зачем нужна защита web-приложений?
Безопасность веб-приложений — это защитные меры, при которых злоумышленник не сможет получить доступ к конфиденциальным данным как извне при попытке взлома, так и внутри компании через нелегитимный доступ.
А если инсайдером окажется привилегированный пользователь — он не сможет воспользоваться конфиденциальными данными, так как его нетипичное поведение будет расценено как аномалия, и об этом немедленно будет оповещена служба информационной безопасности.
Веб-приложения становятся финансово-привлекательными не только для их разработчиков, но и для желающих нелегально воспользоваться данными, хранящимися в них. Виды и число атак на них растут в геометрической прогрессии. Атаки можно условно поделить на две категории угроз ИБ:
нарушение конфиденциальности информации;
нарушение доступности информации.
Наиболее распространенная угроза безопасности web-приложений — это эксплуатация уязвимостей, а при популяризации приложения в интернете — не избежать и DDoS-атак. Для взлома и вывода приложения из строя могут использоваться различные инструменты как любительские, так и профессиональные кибератаки и использование автоматических систем сканирования для эксплуатации уязвимостей.
Первый шаг злоумышленника при попытках атак — сканирование с помощью различных утилит. Это может увидеть администратор по частому обращению с одного IP-адреса к разным страницам и большому числу ошибок 404. Поэтому безопасность веб-приложений начинается с непрерывного мониторинга.
Защита веб-приложений актуальна в любых условиях — в том числе и внутри периметра компании. В большинстве случаев доступ к ним имеют не только офисные работники, но и удаленные сотрудники, которые нередко заходят в них с личных компьютеров в обход VPN. И если не обеспечить непрерывный мониторинг доступа к запросам и ответам, может произойти утечка ценной информации.
Чем грозит утечка конфиденциальной информации из веб-приложения?
Риски делятся на две основные группы:
Например, «горячие» лиды из CRM могут быть перепроданы прямым конкурентам нечестным сотрудником. Утечка клиентской базы, в результате которой клиентские данные оказались в продаже на черном рынке или выложены в публичный доступ, подрывает доверие к организации и влечет ответственность в виде штрафных санкций регуляторов.
Поэтому использование веб-приложений в бизнесе и в работе с конфиденциальными данными невозможно без продуманной всесторонней защиты от всех типов существующих угроз и предиктивным подходом к безопасности.
Как обеспечить безопасность web-приложений?
Приложения доступны из Интернета, чем привлекают внимание злоумышленников. Для получения доступа к конфиденциальным данным в них содержащихся, они применяют разнообразные векторы атак.
Прямой способ защиты приложений — межсетевой экран или брандмауэр. Для большего числа веб-приложений применяется прикладной сетевой экран Web Application Firewall (WAF). Если же мы говорим о бизнес-приложениях, которые содержат базы коммерческих и персональных данных, — то здесь требуется другой тип защиты — брандмауэр баз данных Database Firewall (DBF). Это позволяет защитить конфиденциальные данные на разных уровнях.
Применение специализированных решений по информационной безопасности позволяет обнаружить и предотвратить атаки на прикладном и сетевом уровне и реализовать комплекс мер, чтобы обеспечить доступность и непрерывность работы web-приложений за счёт защиты от различных классов атак.
Межсетевой экран автоматически обнаруживает и блокирует атаки на веб-приложения и определяет нелегитимных пользователей, пытающихся проникнуть в веб-приложение.
К основным мерам относятся:
проверка данных на соответствие стандартам протоколов;
контроль трафика на основе нейронных сетей;
защита от SQL-инъекций;
протекция от межсетевого скриптинга (XSS);
контроль доступа к конфиденциальным данным.
Внедрение программно-аппаратных комплексов снижает риски несанкционированного доступа к критичной информации и эксплуатации уязвимостей системного ПО. Более того, наличие специализированных решений по информационной безопасности позволяет обеспечить законодательные требования по защите персональных данных, а также банковских стандартов (СТО БР) и стандарта безопасности данных индустрии платежных карт PCI DSS в вопросах защиты веб-приложений.
Применение специализированных систем защиты web-приложений позволит своевременно обнаруживать и предотвращать попытки несанкционированных действий злоумышленников как внутри организации, так и извне.
Кроме выявления и блокировки атак для защиты данных в приложениях требуется непрерывный мониторинг доступа к базам данных и анализ поведения пользователей и систем. Эти функции обеспечивают решения класса DAM (database activity monitoring). Рассмотрим подробнее принцип работы таких решений.
DAM и DBF — классы систем для защиты веб-приложений
Веб-приложения тесно связаны с СУБД, поэтому атаки, направленные на них могут быть критичными. Получая доступ к приложению, злоумышленник может не только деактивировать его работу, но и завладеть ценной информацией, что грозит крупными финансовыми и репутационными рисками.
Согласно исследованию «Гарда Технологии», базы данных страховых и финансовых компаний оказываются на черном рынке преимущественно из автоматизированных систем, работающих через приложения. Риски утечек могут оцениваться в миллионы долларов. Прибавьте сюда штрафные санкции от регуляторов за нарушение закона о персональных данных и снижение уровня доверия клиентов. Поэтому игнорировать вопрос защиты веб-приложений при веде́нии бизнеса — опрометчивое решение.
Как говорили выше, чтобы защитить бизнес-приложения от современных угроз, одного WAF и сигнатурных средств недостаточно. Требуются специализированные решения для обеспечения безопасности баз данных. Средства по защите баз данных и веб-приложений относятся к классам Database firewall (DBF) / Database Activity Monitoring (DAM) – это аппаратно-программные комплексы для мониторинга, аудита и контроля доступа к информации и защиты от целевых атак на них. Есть решения, объединяющие в себе функциональные возможности по мониторингу, аудиту и защите от атак на базы данных.
В качестве основных функций систем DAM/DBF выделим следующие:
защита от внешних атак;
выявление уязвимостей БД;
обнаружение неучтенных конфиденциальных данных в базах приложений;
блокировка неавторизованных или нетипичных запросов и ответов;
проверка данных на обезличенность при передаче;
тотальный контроль всех запросов к БД и настраиваемые политики безопасности;
построение профилей пользователей и выявление подозрительной активности;
автоматическое сканирование БД на наличие конфиденциальной информации;
расследование инцидентов безопасности;
предотвращение утечек данных.
Обеспечение информационной безопасности веб-приложений с помощью специализированных систем — это комплексная задача бизнеса и возможность нивелировать риски.
Отечественное решение для информационной безопасности веб-приложений
Первое российское решение для обеспечения безопасности веб-приложений классов DBF и DAM стал аппаратно-программный комплекс «Гарда БД» от производителя систем информационной безопасности «Гарда Технологии».
«Гарда БД» изначально разрабатывалась как система защиты баз данных и веб-приложений. И большинство практических кейсов как раз связано с CRM, 1C, банковскими АБС и другими приложениями, которые используются в ежедневной практике работы сотрудников.
Это система аудита и блокировки сетевого доступа к базам данных и бизнес-приложениям. За счет непрерывного мониторинга обращений к базам данных и веб-приложениям детектирует подозрительные действия в реальном времени.
«Гарда БД» за счет сочетания технологических возможностей обеспечивает комплексную защиту: хранение запросов и ответов для дальнейшего ретроспективного анализа, автоматический поиск неконтролируемых баз данных, поведенческий анализ и выявление нарушений политик ИБ, аналитика и автоматическое уведомление об аномалиях.
Систему отличает скорость анализа трафика свыше десяти Гбит/с, что позволяет мгновенно реагировать на аномалии и информировать об этом службу безопасности, ни один подозрительный запрос или атака не останутся незамеченными.
Поведенческая аналитика позволяет выявлять отклонения от нормального поведения сотрудников или приложений. Все данные собираются в наглядные статистические отчеты, где можно видеть все логины, IP-адреса и запросы к базам данных и приложениям за конкретный период времени, а также большое количество запросов и множественные неуспешные авторизации. Контроль осуществляется по протоколам передачи данных HTTP/HTTPS и протоколам аутентификации.
АПК «Гарда БД» — прогрессивное решение, которое позволяет предотвратить инциденты уже по первым признакам аномального поведения пользователей и систем и обеспечить защиту web-приложений от всех видов угроз. Для тестирования системы в организации предусмотрен бесплатный пилотный проект. Уже за первый месяц работы системы удается предотвратить инциденты информационной безопасности в бизнес-приложениях.
Защита веб-приложения: практические кейсы
Безопасность веб-приложений находится в первой десятке трендов и угроз информационной безопасности уже свыше 10 лет. Действительно, современные бизнес-процессы и повседневная жизнь — все больше и больше зависит от использования веб-приложений, в разнообразнейших аспектах: от сложных инфраструктурных систем до IoT устройств. Тем не менее специализированных средств защиты веб-приложений довольно мало, по большей части эту задачу возлагают (или надеются что она будет решена) на разработчиков. Это и использование различных фреймворков, средств санации, очистки данных, нормализации и многого другого. Тем не менее, даже с использованием этих средств безопаснее веб не стал, более того, в все уязвимости «классического веба» практически в неизменном виде мигрировали в мобильную разработку. В этой статье будет рассказано не как не допустить уязвимость, а как защитить веб-приложение от ее эксплуатации с использованием Web Application Firewall.
Из чего складывалась защита веб-приложения раньше? Из грамотной настройки веб-сервера, чистки сайта от ненужных файлов и участков кода и минимального контроля. Действительно, каналы были слабые, DDoS не был распространен, уязвимостей было мало, приложения были простыми, действия пользователей предсказуемы несколькими сценариями.
Со временем усложнялись веб-приложения, серверная инфраструктура и взаимодействие, код становился все более объемным и громоздким — это намного увеличило т.н. «поверхность атаки». Веб стал очень популярным, в нем появились возможности финансового роста — что естественно привлекло в эту сферу желающих незаконно воспользоваться чужим трудом.
Экспоненциально стало расти количество и разновидность атак на веб-приложения, которые условно можно разделить на две категории (исходя из концепции информационной безопасности):
В первую очередь это касается эксплуатации уязвимостей, во вторую атак на отказ в обслуживании. И если часть атак можно попытаться избежать на этапе планирования и разработки приложения (использую инструменты тестирования, отладки, анализ кода и т.д.), то при размещении веб-приложения в сети интернет сайт (особенно популярной сферы деятельности или компании) начинает подвергаться атакам практически по всем направлениям:
Они обладают различными методами, способами и инструментарием — объединяет их только одна цель взломать или вывести из строя веб приложение.
Практика и статистика
Хватит теории, давайте перейдем к практике. Очень часто многие оппоненты из dev апеллируют к тому, что уязвимостей скоро (или уже) не будет, есть фреймворки, модные и секюрные, исходный код проверяют тысчи человек, хакеры скоро вымрут. А как же на практике?
Давайте пройдемся по блогу «информационная безопасность» и посмотрим что было «горячего» за последнее время:
Кейс: 3 апреля: 0day в банковском ПО для геолокации (топик удален)
Тип уязвимости: SQL injection, RCE, Auth Bypass.
Описание: слепая инъекция на форме входа в службу геолокации банка. Сервис критичный, доступен в сети интернет.
Риски: бизнес процессы, безопасность, кража, репутация.
Защита: выявлять и блокировать паттерны эксплуатации SQL инъекции, такие как: использование кавычек, специальных конструкций — в данном примере функции sleep.
Кейс: 24 марта: Взлом сайта доставки пиццы, взлом mobidel.ru
Тип уязвимости: Insecure Direct Object References, хранимая XSS, захват сессии
Описание: отсутствие каких-либо проверок, классические клиент-сайд атаки.
Риски: бизнес процессы, безопасность, кража, репутация.
Защита: выявлять и блокировать паттерны эксплуатации XSS вектора — использование функций инъекций html кода, множества запросов авторизации с разными id.
Кейс: 22 марта: Немного о приватности реальных Git-репозиториев
Тип уязвимости: Insecure Direct Object References, раскрытие информации
Описание: прямой доступ к критичным объектам.
Риски: получения информации о приложения для развития атаки.
Защита: выявлять и блокировать множественные обращения к служебным файлам репозитория.
Кейс: 12 марта: Надёжная авторизация для веб-сервиса за один вечер
Тип уязвимости: SQL injection
Описание: типичный разработчик, фигак-фигак и в продакшн.
Риски: security through obscurity.
Защита: выявлять и блокировать паттерны эксплуатации SQL инъекции (union, select и т.д.) — даже зная где она находится (при наличии исходного кода), злоумышленник не сможет ее проэксплутировать.
Кейс: 6 марта: Как взламывают телеком-провайдеров: разбор реальной атаки
Тип уязвимости: SQL injection
Описание: взлом периметра через веб, проникновение в сеть.
Риски: бизнес процессы, безопасность, кража, репутация.
Защита: выявлять и блокировать паттерны использования автоматических средств поиска уязвимостей (по заголовкам, частоте (парсингу) обращений.
Это все то, что как говорится «на виду». Веб-приложения как ломали, так и будут ломать дальше. Никакие инструкции по разработке безопасного кода, рекомендации, бест-прэкстис и т.д. не работают. Необходимы дополнительные защитные, или даже страховочные меры, для того чтобы предотвратить взлом веб-приложения. Это не значит что современные WAF — панацея. Это одна из защитных мер, которая поможет предотвратить взлом веб-приложения.
Выявление паттернов
Давайте разберем основные паттерны из представленных выше кейсов.
Инъекции
Эксплуатация sql-инъекции. В первую очередь злоумышленник (или автоматической средство) будет смотреть на поведение приложения, при подстановке в тот или иной параметр кавычки:
Будем считать, что инъекция есть, и сайт нам выведет ошибку (классика) you have an error in your sql syntax. Можем ли мы блокировать простую кавычку? По идее да, но вот что делать с фамилиями типа О’Коннор, служебными или админ-панелями, где применение кавычки вполне уместно? (та же markdown-разметка даст нам множество false-детектов).
Такие запросы напрямую не относятся к эксплуатации, это можно назвать зондированием, probe-запросом, который помогает злоумышленнику обнаружить признак уязвимости. Т.е. такие запросы должны блокироваться, но в тех зонах, где не определено другое правило. Также, необходимо осуществлять проверку IP-адреса, откуда пришел запрос: если ранее с этого адреса были атаки, он в черном списке и т.д. — можно осуществлять блокировку на основе репутационной политики.
Злоумышленник нашел уязвимость, теперь он попытается ее проэкплуатировать (для начала подобрать количество полей):
Либо, как в первом примере:
Эти запросы явно относятся к попыткам эксплуатации (и их как правило много) и должны быть заблокированы защитными средствами. Но, стоит учитывать область применения — если это находится в теле запроса, необходимо проводить преобразование (либо очистку) опасных конструкций средствами веб-приложения. Как например в моей статье — хабр не ругается на сломанный синтаксис запроса и дает мне нормально опубликовать кавычку и паттерн атаки (без выполнения).
Атака. Злоумышленник знает как устроено веб-приложение (у него есть код, как из примера выше), он может заранее подготовить конструкцию для атаки, например с применением специальных запросов типа drop/infile/outfile/dumpfile/load_file:
Это явная атака и она должна быть заблокирована (опять же по зоне применения правила). Если брать за основу балльную систему — то эта конструкция должна получить множество штрафных баллов: использование паттерна union select (и вариаций), функции LOAD_FILE, наличия спецсимволов и их потенциально опасных комбинаций (‘/, обращений к служебным файлам /etc/passwd, и символов терминации/комментирования /*.
Теперь перейдем к XSS. Тут вариаций пейлоадов довольно много, они более разнообразные и сложные. В этом случае необходимо и защищать веб приложение и давать возможность пользователю вводить данные в формы ввода, не блокируя его. Это необходимо делать, как на уровне приложения, так и средствами защиты.
К примеру, простейшая форма ввода телефона (возьмем вариант без валидации вводимых значений и типов) может быть заполнена пользователем в силу его умений и фантазии:
канонично:
со сломанным пробелом:
на европейский манер:
Т.е. пользователь даже в такой простой форме может использовать несколько вариаций использования символов и их комбинаций, что говорить про большие веб-формы, которые содержат множество полей? А если они предполагают украшение/выделение текста? Ваша компания:
Конечно такой запрос не будет блокироваться, опасных комбинаций здесь нет. «Обычные» xss-зонды, тоже выявляются довольно просто:
Это может дать выявить попытки эксплуатации уязвимости, поэтому такие запросы будут заблокированы.
Есть и более серьезные запросы на выявления XSS — например классика жанра (практически не устаревающая) — универсальный XSS вектор от raz0r:
В этом запросе есть практически все, чтобы «выстрелить» при наличии XSS. Такой запрос — это явная атака и он должен быть немедленно заблокирован.
Сканеры уязвимостей
Обычно предвестником атаки является сканирование веб-приложения теми или иными утилитами. Явный признак: частое обращение с одного IP к разными страницам, больше количество 404 ошибок. Это может быть поисковый бот (его ни в коем случаем не баним, но и при этом мы должны быть точно уверены что это именно бот — проверка поля User Agent не даст таких гарантий). Это может быть краулер или парсер — если нам не жалко — пусть парсит, можно лишь ограничить ему «аппетит» количеством запросов в минуту, если у вас слабый сервер. Другое дело сканеры: в первую очередь их можно сразу же определить по User Agent/служебным заголовкам (а большинство из тех, кто ими пользуется, никогда его не меняют и скорее всего даже не догадываются об этом): например сразу же выявляются такие сканеры, как: acunetix, w3af, netsparker, nikto и т.д. Такие обращения необходимо блокировать сразу же, чтобы не облегчать злоумышленникам работу (и не засорять логи). Если заголовки все-таки замаскированы — определить сканер можно по множеству 404 ошибок, попыток авторизации и обращений к служебным файлам.
Защита
Как мы видели в вышеприведенных примерах, используются разные технологии, платформы — поэтому современные защитные средства должны это учитывать. Во всех случаях использование WAF могло бы предотвратить эксплуатацию уязвимости, а система уведомлений сообщить о попытке эксплуатации.
Для того, чтобы избежать эксплуатации тех или иных уязвимостей, современный WAF должен: