Этот пост посвящен Content Security Policy (CSP), а точнее способам ее обхода в современных реалиях.
Для начала немного базы:
Content Security Policy (CSP) — это механизм веб-безопасности, реализованный через HTTP-заголовок, который позволяет владельцам сайтов ограничивать источники загрузки контента (скриптов, стилей, изображений, и т д) посредством определенных директив. Наиболее эффективен в защите от XSS и Clickjacking.
CSP - довольно мощный инструмент, но крайне сложный в правильной настроке. Часто бывает, что при настройке очень строгих политик ломается часть бизнес-функций, что убивает стремление к полной безопасности и создаются дыры. На своей практике я очень редко встречал полностью безопасные настройки CSP, особенно в реалиях русских приложений (тут отсылка к названию поста).
Итак, пост про обход - так как обходить? Первое, что нужно сделать - это детально изучить, что нам дает CSP. Для этого есть даже замечательный инструмент - он сразу может показать верхнеуровневые проблемы вашей CSP. Далее, нас интересуют следующие конструкции:
- Наличие unsafe-inline, unsafe-eval. Если есть такое, то это открытые двери к XSS, даже изобретать ничего не нужно - работают стандартные нагрузки.
- Наличие протокола data в script-src. Почти предыдущий случай, но тут нужно чуть более сложную нагрузку составить (в data мы можем передать закодированный или чистый скрипт на исполнение. У него свой формат, но разобраться несложно).
- Наличие strict-dynamic/nonce-. Тут уже интереснее - для скриптов используется nonce- рандомное значение, которое определяет, можно ли скрипту запуститься. Единственная проблема, которая тут может быть - статичный или предсказуемый nonce. Если вы сможете уверенно сказать, какой будет nonce при следующем запросе, то вы легко можете подменить его в своем скрипте и запustиться.
- Отсутствие директивы form-action. Это не крит, но открывает дорогу к CSRF. Однако, обычно от CSRF защищаются не этим способом, поэтому маловероятно, что это поможет.
- Попадание пользовательского ввода в директивы CSP. Тут классика - если мы можем туда что-то дописать, то можем открыть сами себе путь к эксплуатации. Есть хорошая лаба на портсвиггере на эту тему
- Наличие известных эксплоитов в жестко прописанных доменных именах. Тут может помочь этот инструмент. На самом деле защита в данной ситуации падает очень часто, потому что даже на легальных сервисах гугла и яндекса, которые обычно разрешены для в целях аналитики в CSP есть известные XSS-сплоиты (можете для примера закинуть в инструмент mc.yandex.ru и получить рабочий XSS-сплоит с вызовом колбек-функции в JS), который обходит CSP, где данный домен разрешен (а разрешение его и подобных доменов у нас сильно не редкость).
На этом пока все, храните свой контент в безопасности!
#csp #csp_bypass
☠️ Hunt Or Be Hunted
