Comments 7
Удивительно, что CSP (Content Security Policy) изобрели чудовищно давно, а XSS до сих пор работают.
Увы, в таких реалиях мы живем - даже максимально примитивные XSS как описал в начале статьи - не редкость)
Возможно, это потому, что данная атака является по своей сути "нативной", то есть если не защищаться от нее специально - она будет присутствовать. В то же время, если неправильно выставить защиту как та же CSP - они будут обходиться и мы будем снова возвращаться в исходной точке
Очень интересный кейс, спасибо
Имел знакомство с WAF F5, как разработчик веб сервисов, которого «защищают».
В двух организациях последовательность действий была одинакова:
Обучали
Включили
Какие-то странные ошибки. Ах, это WAF!
Снова обучение
Включение на 5 минут и затем снова переход в обучение
Каждый месяц ситуация повторяется
Режим вечного обучения
Пришёл новый безопасник и решил включить в пятницу, ближе к 17:30
Ты чё творишь? Сам будешь объяснительную писать, почему сервисы полчаса не работали
...
Иногда мне посылали отчёты всего то, что WAF в режиме обучения посчитал вредным, после недели такого спама эксперимент закончился.
Имел опыт администрирования бесплатного Snort-а и, исходя из тех отчётов кажется, что WAF F5, это Snort но за деньги.
Ещё один кейс вам в копилку: как-то раз нашёл урл, который позволяет устанавливать значения кук гетом
WAF не было, но можно было прописать очень длинное значение
А т.к. у рядового пользователя по дефолту уже с килобайт кук, то навешивание ещё нескольких кб приводило к тому, что nginx основного приложения вместо красоты писал что-то вроде "too long headers"
Спасибо, довольно интересный кейс. У этой атаки даже название имеется - cookie bomb. Результат, в целом, такой же как и описывается в статье.
Она тоже не сильно популярна, но ее вот даже на bugbounty сдавали (по ссылке выше есть пример).
Client-Side DoS, или, ещё одна уязвимость, за которую вам не заплатят