блокировать csp отчеты что это
Улучшение сетевой безопасности с помощью Content Security Policy
Content Security Policy (CSP, политика защиты контента) — это механизм обеспечения безопасности, с помощью которого можно защищаться от атак с внедрением контента, например, межсайтового скриптинга (XSS, cross site scripting). CSP описывает безопасные источники загрузки ресурсов, устанавливает правила использования встроенных стилей, скриптов, а также динамической оценки JavaScript — например, с помощью eval. Загрузка с ресурсов, не входящих в «белый список», блокируется.
Принцип действия
CSP сейчас является кандидатом в рекомендации консорциума W3C. Для использования политики страница должна содержать HTTP-заголовок Content-Security-Policy с одной и более директивами, которые представляют собой «белые списки». В версии 1.0 поддерживаются следующие директивы:
Для всех директив действуют следующие правила:
Content-Security-Policy: default-src ‘self’;
Попытка загрузки ресурсов из иных доменов будут пресекаться браузером с выдачей уведомления в консоли:
По умолчанию CSP ограничивает исполнение JavaScript путём запрета встроенных скриптов и динамической оценки кода. В комбинации с «белыми списками» это позволяет предотвращать атаки с внедрением контента. Например, XSS-атаку с внедрением тэга инлайн-скрипта:
Загрузка внешних скриптов, которые не включены в CSP, также будет пресечена:
На данный момент в перечне URL нельзя прописывать пути ( http://cdn.example.com/path ), можно лишь перечислять сами домены ( http://cdn.example.com ). Зато поддерживаются символы подстановки, так что вы можете описать сразу все поддомены ( http://*.example.com ).
Поддержка браузерами
Получение отчётов о нарушениях CSP
Допустим, у нас есть такая CSP:
Это означает, что браузер может загружать ресурсы только с нашего собственного домена. Но нам нужно использовать сервис Google Analytics, который будет пытаться скачивать JavaScript с www.google-analytics.com. А это уже нарушение нашей CSP. В этом случае report-uri отправит запрос со следующим JSON:
Content-Security-Policy-Report-Only
Прописывание заголовка
HTTP-заголовок можно прописать прямо в конфигурационных файлах на сервере:
Также многие языки программирования и фреймворки позволяют добавлять заголовки программно (например, PHP, Node.js):
CSP в дикой природе
Давайте посмотрим, как CSP внедрён в Facebook:
А теперь вариант Twitter:
CSP Level 2
Также является кандидатом в рекомендации. В CSP Level 2 сделаны следующий нововведения:
Nonce — это генерируемая случайным образом на сервере строковая переменная. Она добавляется в CSP-заголовок:
и в тэг инлайн-скрипта:
Пример хэша, сгенерированного из строковой console.log(‘Hello, SitePoint’); с помощью алгоритма Sha256 (base64).
Во время рендеринга страницы браузер для каждого инлайн-скрипта вычисляет хэши и сравнивает с перечисленными в CSP. Приведённый выше хэш позволяет выполнить скрипт:
Content Security Policy — опасная политика
Обзор нового веб-стандарта и его фундаментальных уязвимостей
Чтобы идти в ногу со временем, браузеры внедряют все новые технологии для обеспечения безопасности пользователей. Одна из них — Content Security Policy, позволяющая разработчикам сайтов четко объяснить браузеру, на какие адреса тот может выполнять межсайтовые запросы. Однако новый веб-стандарт страдает от существенных недостатков, ставящих под сомнение его пригодность как защиты от XSS.
Content Security Policy vs Same Origin Policy
Одним из главных принципов безопасности браузеров и веба в целом является Same Origin Policy — дословно «политика единого источника» (устоявшегося термина до сих пор не существует). Ее суть заключается в проверке трех компонентов, из которых состоит origin: протокол, хост и порт. Если страница http://test1.ru/a.html пытается получить доступ к DOM страницы http://test2.ru/b.html, то у нее ничего не выйдет, так как хосты отличаются. Если бы SOP не существовал, любой сайт мог бы делать запросы на произвольные адреса и получать оттуда данные, что, как подсказывает логика, не есть хорошо. Причем страдали бы все: как пользователи, чьи персональные данные летали бы без принуждения, так и владельцы ресурсов, — в общем, в вебах творился бы полный хаос. Поэтому Same Origin Policy всех спасает и все счастливы. Однако есть одно но: что, если на страницу http://test1.ru/a.html внедрен злой скрипт с сайта http://test2.ru/, который делает плохие штуки в контексте браузера жертвы? В данном случае SOP бесполезен, ибо на
Очевидно, что такой подход не поможет защититься от случаев, когда у атакующего есть возможность внедрить код в скрипт с валидным токеном. Кроме того, есть масса вариантов обхода, о чем пойдет речь ниже.
CRLF Injection
При наличии CRLF-инъекции в заголовках ответа, то есть отсутствии фильтрации символа переноса строки, у атакующего есть возможность банального обхода CSP с помощью внедрения собственных директив. Здесь большую роль играет то, какой заголовок браузер будет использовать при наличии нескольких с одинаковым именем. Как в случае с HTTP Parameter Pollution, где одинаковые имена параметров обрабатываются по-разному на разных платформах, при внедрении еще одного заголовка Content-Security-Policy важно, где он окажется — перед первоначальным или после него, так как один браузер может взять последний заголовок, а другой — первый. Так, если браузер отдает приоритет первому и мы внедряем наш CSP перед настоящим, то обход тривиален:
Если же используется последний встреченный заголовок, то мы можем отправить его в тело страницы, отправив rnrn:
Таким образом, первоначальный заголовок попадет в содержание HTTP-ответа и не будет иметь силы.
Scriptless Attacks
Перейдем к более интересным вариантам обхода — на стороне клиента. Основная цель межсайтового скриптинга — получить некую приватную информацию пользователя, которая обычно хранится в cookie. Однако с введением таких мер защиты, как флаг httpOnly, запрещающий JS-скриптам доступ к защищаемым cookie, внедрением в браузеры XSS-фильтров (XSS Auditor в Chrome, XSSFilter в IE), собственно и самого CSP, исследователи безопасности все чаще обращают внимание на другие цели, например личные данные, различного рода токены (CSRF, oAuth, в скором будущем и script-nonce). При этом используются новые способы отправки данных на сторонние сайты, без JavaScript!
CSSAR
Еще в 2008 году Эдуардо Вела (Eduardo Vela), Дэвид Линдсей (David Lindsay) и Гарет Хейс (Gareth Heyes) представили технику чтения атрибутов тегов с помощью CSS-селекторов. На данный момент техника все так же актуальна. Если раньше она позиционировалась как обход NoScript, то сейчас ее можно использовать и для CSP. Суть CSSAR (CSS Attribute Reading) в брутфорсе значений с помощью селекторов атрибутов. Для этого на уязвимую страницу подключается CSS-файл с комбинациями выражений:
Если значение целевого инпута начинается с «a», то будет отправлен запрос на сайт атакующего через подгрузку фонового изображения, относящегося к соответствующей комбинации символов. CSS не имеет возможности указать позицию символа, поэтому для получения следующего знака необходимо сгенерировать массу вариантов вида
Поэтому конечный PoC может иметь объем в несколько сотен килобайтов.
CSSAR в действии
Вариант обхода № 4. Postcards from post-XSS world
Интересные идеи предложил Михал Залевски (Michal Zalewski). Например, имея внедрение кода перед формой, защищенной CSRF-токеном, можно вставить незакрытый тег img:
Все содержание страницы до следующей закрывающей кавычки, включая и целевой токен, после незакрытого атрибута src будет отправлено на сайт атакующего.
Content Security Policy (CSP)
CSP разрабатывался с возможностью полной обратной совместимости (за исключением CSP version 2, в которой были намеренно определены некоторые противоречия блокирующие обратную совместимость; с деталями можно ознакомиться здесь, в пункте 1.1). Браузеры, которые не поддерживают CSP, все ещё могут работать с серверами, которые поддерживают CSP, и наоборот: браузеры, в которых поддержка CSP отсутствует, будут её игнорировать, продолжая работу в соответствии со стандартными правилами ограничения домена для загрузки контента. В случае, если сайт не предоставляет CSP-заголовки, браузеры, в свою очередь, будут использовать стандартные правила ограничения домена.
Угрозы
Межсайтовый скриптинг
Основная цель создания CSP заключается в устранении XSS-атак и сборе данных об их попытках. XSS-атаки используют доверие браузера к контенту, полученному с сервера. Зловредные скрипты исполняются в браузере жертвы, поскольку браузер доверяет источнику, даже когда скрипт поставляется не оттуда, откуда кажется.
CSP даёт возможность администраторам серверов снизить или полностью устранить вектора, по которым злоумышленники могут провести XSS, с помощью определения доменов, которые браузер клиента должен считать доверенными источниками исполняемых скриптов. В таком случае, браузер, совместимый с CSP, будет исполнять только те скрипты, которые были получены из списка разрешённых источников, и игнорировать прочие (в т.ч. встраиваемые скрипты и обработчики событий, указанные непосредственно в HTML-атрибутах).
В качестве крайней меры защиты, сайты, которые хотят запретить исполнение скриптов, могут настроить это поведение глобально, с помощью соответствующей опции.
Пакетный сниффинг
В дополнение к ограничению количества доверенных доменов, с которых разрешается получать контент, можно также ограничить список используемых протоколов; например (в идеале и это крайне желательно с точки зрения обеспечения безопасности), сервер может поставить ограничение на получение контента только по HTTPS. Завершённая стратегия защиты передачи данных должна включать в себя не только принуждение к использованию HTTPS, но также и пометку всех кук с помощью специального флага, а также перенаправление запросов с HTTP на HTTPS. Сайты также могут использовать Strict-Transport-Security HTTP-заголовок, чтобы обеспечить подключение к ним браузеров только по защищённому каналу.
Использование CSP
Настройка CSP включает в себя добавление на страницу HTTP-заголовка Content-Security-Policy (en-US) и его настройку в соответствии со списком доверенных источников, из которых пользователь может получать контент. Например, страница, на которой происходит загрузка и отображение изображений может разрешать их получение из любых источников, но ограничить отправку данных формы конкретным адресом. При правильной настройке, Content Security Policy поможет защитить страницу от атак межсайтового скриптинга. Данная статья описывает как правильно настроить необходимые заголовки и примеры, как это сделать.
Определение политики
Вы можете начать настройку Content-Security-Policy (en-US) с определения HTTP-заголовка и указания какую политику использовать:
Создание политики
Примеры: Распространённые случаи применения
В данном разделе приводятся наиболее распространённые сценарии использования CSP.
Пример 1
Вы хотите ограничить источники контента только исходным сервером (исключая поддомены)
Пример 2
Вы хотите разрешить получение контента с доверенного домена и всех его поддоменов (доверенный домен не обязательно должен совпадать с тем, на котором настраиваются CSP.)
Пример 3
Вы хотите разрешить пользователям приложения вставлять в создаваемый ими контент картинки из любого источника, но при этом ограничить источники аудио- и видео-файлов списком доверенных провайдеров. Получение скриптов должно происходить только с конкретного сервера, содержащего доверенный код.
При такой настройке, весь контент доступен для получения только с исходного домена, со следующими исключениями:
Пример 4
Вы хотите удостовериться, что весь получаемый контент для онлайн-банкинга идёт по SSL и атакующий не сможет обрабатывать запросы:
Пример 5
Для просмотра писем в почтовом клиенте вы хотите разрешить использование HTML внутри письма, а также позволить загрузку изображений из любых источников, но запретить использование любого JavaScript-кода и прочий потенциально опасный контент.
Заметьте, что в настройке политики отсутствует директива script-src (en-US); при такой настройке CSP при загрузке скриптов будут использоваться настройки, определяемые директивой default-src (en-US), следовательно все скрипты могут быть загружены только с исходного домена.
Тестирование настройки политики
Для облегчения развёртывания можно настроить развёртывание CSP в режиме report-only. Таким образом, политика не будет ограничивать загрузку, но будет сообщать обо всех нарушениях на указанный в заголовке URI. Кроме того, заголовок report-only может использоваться для тестирования новой политики без полноценного развёртывания.
Для определения вашей политики вы можете использовать заголовок Content-Security-Policy-Report-Only (en-US) следующим образом:
Настройка отправки отчётов
По умолчанию, отправка отчётов не производится. Для того чтобы включить отправку отчётов, необходимо в вашей политике определить директиву report-uri (en-US) и указать как минимум один URI, куда будут направляться отчёты:
Кроме того, необходимо настроить свой сервер на получение этих отчётов; вы можете хранить и обрабатывать эти отчёты как считаете нужным.
Синтаксис отчёта о происшествиях
Объект отчёта в формате JSON содержит следующие поля:
Пример отчёта о происшествии
Совместимость с браузерами
BCD tables only load in the browser
Для некоторых версий Safari существует специфическая несовместимость реализации CSP. Если установить заголовок Content Security Policy без заголовка Same Origin, то браузер начнёт блокировать и создавать ложно-положительные отчёты о нарушении политики для всего контента, как с запрашиваемого источника, так и из внешних источников.
Разрешено все! Изучаем новую крутую технику обхода CSP
Содержание статьи
Типичный пример использования CSP — это разрешение загрузки ресурсов с собственного домена (self) и разрешение выполнения инлайн-сценариев:
Xakep #234. Взломать iPhone
Запрещено грузить любой контент с внешних источников, в том числе изображения, CSS, WebSocket. И конечно же, JS.
Для примера я специально оставил XSS в этом месте, задача — украсть секрет пользователя.
Но не стоит забывать, что self позволяет работать в контексте SOP в рамках этого домена, поэтому мы по-прежнему можем грузить сценарии, создавать фреймы, изображения. Если вспомнить о фреймах, то CSP распространяется и на фреймы, в том числе если в качестве протокола будет указан data, blob или будет сформирован фрейм с помощью атрибута srcdoc.
WARNING
Статья написана в исследовательских целях. Вся информация в ней носит ознакомительный характер. Ни автор, ни редакция не несет ответственности за неправомерное использование упомянутых в ней аппаратных платформ, программ и техник!
Можно ли выполнить JS в текстовом файле?
Для начала вспомним один трюк. Если современный браузер открывает изображение или какой-то текстовый файл, он автоматически преобразуется в HTML-страницу.
Но что, если фрейм будет содержать страницу сайта, но уже без заголовка CSP? Вопрос риторический. Выполнит ли открытый фрейм без политики все JS, которые будут у него внутри? Если иметь XSS на странице, мы можем сами записать свой JS внутрь фрейма.
Для теста сформируем сценарий, который открывает iframe. Для примера возьмем bootstrap.min.css, путь к которому указан на странице выше.
Теперь посмотрим на содержимое фрейма. Отлично! CSS был преобразован в HTML, и нам удалось переписать содержимое head (хотя оно было пустое). Теперь проверим, сработает ли в нем подключение внешнего JavaScript-файла.
Таким образом мы можем выполнить инъекцию через iframe, создать в нем свой JS-сценарий и обратиться в окно-родитель, чтобы украсть оттуда данные.
Для полноценной эксплуатации XSS достаточно открыть фрейм с любым путем, где отсутствует политика безопасности. Это могут быть стандартные favicon.ico, robots.txt, sitemap.xml, CSS/JS-файлы, загруженные пользователями изображения и прочее.
Ошибки сервера для обхода CSP
Но что, если любой корректный ответ (200 — OK) содержит X-Frame-Options: Deny? Вторая ошибка, которую допускают при внедрении CSP, — это отсутствие защитных заголовков при ошибках веб-сервера. Самый простой вариант — обратиться на несуществующую страницу. Я заметил, что многие ресурсы ставят X-Frame-Options только на ответы 200, но 404 игнорируют.
Если и это предусмотрено — попробуем вызвать стандартное сообщение от веб-сервера о некорректной ссылке.
Однако самый простой способ получить ошибку веб-сервера — это превышение длины URL. Современные браузеры могут сформировать ссылку много больше, чем поддерживает веб-сервер. А у веб-серверов по умолчанию размер ссылки не должен превышать 8 Кбайт данных, как в nginx, так и в Apache.
Для этого вызываем похожий сценарий, например с длиной пути в 20 000 байт:
Если вспомнить о других лимитах — это длина кук. Количество и длина кук в браузере может быть больше, чем поддерживают веб-серверы. По аналогии:
Создаем огромные cookie:
Открываем фрейм на любой адрес, сервер вернет ошибку (и часто без XFO и CSP).
Удаляем огромные cookie:
Пишем в фрейм свой JS-сценарий, который ворует secret.
Попробуй сам! А если не получится, вот тебе PoC :).
Скорее всего, есть и другие способы вызвать ошибку, например отправить слишком длинный POST-запрос или вызвать ошибку самого веб-приложения (например, с ошибкой 500).
Почему это работает?
Потому что политика подключаемого ресурса в фрейме контролируется самим ресурсом.
На сайте Useless CSP ты найдешь множество примеров сайтов, на которых неверно настроена CSP, что сводит всю защиту на нет.
Как этого избежать
Заголовок Content-Security-Policy должен присутствовать на всех страницах, даже на ошибках веб-сервера.
Настройка CSP должна происходить таким образом, чтобы права были минимально необходимыми для корректной работы ресурса, если это возможно. Попробуй включить Content-Security-Policy-Report-Only: default-src ‘none’ и постепенно включать правила для тех или иных ситуаций.
Bo0oM
Security researcher, whitehat, bug bounty practicant, blogger, noob, script kiddie.
Плагин uBlock Origin блокирует сообщения о кибератаках
Основная задача плагина uBlock Origin – блокировка нежелательной рекламы, однако вместе с тем плагин блокирует инструмент CSP. Content security policy (политика защиты контента) предотвращает внедрение вредоносного JavaScript кода и XSS-атаки. Проблему обнаружил исследователь безопасности Скотт Хелме.
CSP (Политика защиты контента) – дополнительный уровень безопасности, который помогает обнаружить и смягчить некоторые виды атак. Благодаря этой функции разработчики и администраторы сайта могут узнавать о попытках эксплуатации уязвимостей в коде и не допускать эксплуатацию ресурса злоумышленниками.
Как выяснилось, uBO для браузеров Chrome и Firefox блокирует все отчеты CSP, если на странице разрешен какой-либо скрипт, затрагивающий конфиденциальность пользователя (например, скрипт Google Analytics). Web-сайты не получают предупреждения от браузеров о попытках осуществления XSS-атак, если uBO установлен и активен.
Разработчик плагина Реймонд Хилл объяснил, что эта функция является предусмотренной и, если пользователю необходимо, чтобы отчеты CSP все же отправлялись, он может добавить нужный ему скрипт в список исключений плагина вручную.
Хелме выступил против данной функции в плагине. По его словам, uBO может блокировать Google Analytics, не мешая отправке отчетов CSP.
Хилл в свою очередь отметил, что отчеты CSP являются потенциальной угрозой конфиденциальности, так как данные отправляются на удаленный сервер. Отчеты CSP помогают владельцу сайта исправлять проблемы при настройке сервера, однако они вообще не затрагивают возможные проблемы пользователей. По словам разработчика, CSP – всего лишь маркетинг.
Среди исследователей безопасности этот спор вызвал оживленную дискуссию. Компромисс пока не найден, но Хилл пообещал изучить эту проблему и посмотреть, возможно ли блокировать только определенные отчеты CSP.