Безопасность веб-приложений находится в первой десятке трендов и угроз информационной безопасности уже свыше 10 лет. Действительно, современные бизнес-процессы и повседневная жизнь — все больше и больше зависит от использования веб-приложений, в разнообразнейших аспектах: от сложных инфраструктурных систем до IoT устройств. Тем не менее специализированных средств защиты веб-приложений довольно мало, по большей части эту задачу возлагают (или надеются что она будет решена) на разработчиков. Это и использование различных фреймворков, средств санации, очистки данных, нормализации и многого другого. Тем не менее, даже с использованием этих средств безопаснее веб не стал, более того, в все уязвимости "классического веба" практически в неизменном виде мигрировали в мобильную разработку. В этой статье будет рассказано не как не допустить уязвимость, а как защитить веб-приложение от ее эксплуатации с использованием Web Application Firewall. Из чего складывалась защита веб-приложения раньше? Из грамотной настройки веб-сервера, чистки сайта от ненужных файлов и участков кода и минимального контроля. Действительно, каналы были слабые, DDoS не был распространен, уязвимостей было мало, приложения были простыми, действия пользователей предсказуемы несколькими сценариями. Со временем усложнялись веб-приложения, серверная инфраструктура и взаимодействие, код становился все более объемным и громоздким — это намного увеличило т.н. "поверхность атаки". Веб стал очень популярным, в нем появились возможности финансового роста — что естественно привлекло в эту сферу желающих незаконно воспользоваться чужим трудом. Экспоненциально стало расти количество и разновидность атак на веб-приложения, которые условно можно разделить на две категории (исходя из концепции информационной безопасности): В первую очередь это касается эксплуатации уязвимостей, во вторую атак на отказ в обслуживании. И если часть атак можно попытаться избежать на этапе планирования и разработки приложения (использую инструменты тестирования, отладки, анализ кода и т.д.), то при размещении веб-приложения в сети интернет сайт (особенно популярной сферы деятельности или компании) начинает подвергаться атакам практически по всем направлениям: Они обладают различными методами, способами и инструментарием — объединяет их только одна цель взломать или вывести из строя веб приложение. Хватит теории, давайте перейдем к практике. Очень часто многие оппоненты из dev апеллируют к тому, что уязвимостей скоро (или уже) не будет, есть фреймворки, модные и секюрные, исходный код проверяют тысчи человек, хакеры скоро вымрут. А как же на практике? Давайте пройдемся по блогу "информационная безопасность" и посмотрим что было "горячего" за последнее время: Это все то, что как говорится "на виду". Веб-приложения как ломали, так и будут ломать дальше. Никакие инструкции по разработке безопасного кода, рекомендации, бест-прэкстис и т.д. не работают. Необходимы дополнительные защитные, или даже страховочные меры, для того чтобы предотвратить взлом веб-приложения. Это не значит что современные 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 должен: информационная опасность