Cache-Poisoned Denial-of-Service (CPDoS). Часть 2 Так, ну сей | 🇺🇦 DevOps простыми словами

Cache-Poisoned Denial-of-Service (CPDoS). Часть 2

Так, ну сейчас все используют CDNы! Мне бояться такого на продакшне или нет?
Хорошая новость тут в том, что атака известна с 2019 года, и многие крупные CDN научились с ней бороться.
Несмотря на то, что должно совпасть несколько условий со стороны ориджин сервера и CDN провайдера, наиболее уязвимым оказался AWS CloudFront, т.к. их настройки позволяли укладывать на лопатки в основном с помощью HHO и HMC огромную часть фреймворков и веб-серверов, включая S3 . В итоге, они просто запретили кешировать ошибочные ответы от ориджина. Впрочем, большинство провайдеров начали делать тоже самое, либо выставляют очень маленькое время кеширования ошибочных ответов. Также были уязвимы Cloudflare, Akamai, CDN77, Fastly, но только в связке с IIS, ASP.NET, Flask и Play 1.

Еще один способ бороться с этим самостоятельно - это выставлять на все свои ошибочные ответы/страницы хедер Cache-Control: no-store.

Третий способ - выставить WAF перед вашим бекендом.

Так, ну мы вообще не используем никаких кешей перед бекендом, мне эти ваши CPDoSы побоку!
А вот и нет! Например известная опенсорс CMS Drupal имеет внутренний кеш, который подвержен подобным атакам. Только там все игрища происходят вокруг X-Forwarded-Host и Host хедеров, в которые можно вставить как свой хост, так и JS скрипты. Ресерчеры также накопали всякие более извращенные отравления типа DOM, CORS и прочих.