Здравствуйте, дорогие друзья.

Content Security Policy (CSP) — это специальный HTTP-заголовок, используемый для предотвращения определенных типов атак, таких как межсайтовый скриптинг (XSS). Некоторые инженеры считают, что CSP — это волшебное средство против уязвимостей, подобных XSS, но при неправильной настройке могут возникнуть ошибки в настройках, которые позволят злоумышленникам полностью обойти CSP.

Основы политики безопасности контента (CSP)

Заголовок CSP довольно прост, и вам нужно понять всего несколько вещей. Во-первых, значение заголовка CSP состоит из директив, разделенных символом точка с запятой “;” . Вы можете рассматривать эти директивы как политики, применяемые к вашему сайту. Список этих директив приведен ниже, обратите внимание, что это не все из них, но наиболее популярные:

● По умолчанию -src

○ Это служит основой для всего остального.

● Script-src

○ Описывает, откуда мы можем загружать файлы javascript

● Style-src

○ Описывает, откуда мы можем загружать таблицы стилей

● Img-src

○ Описывает, откуда мы можем загружать изображения

● Connect-src

○ Применяется к AJAX и Websockets

● Font-src

○ Описывает, откуда мы можем загружать шрифты

● Object-src

○ Описывает, откуда мы можем загружать объекты (<вставлять>)

● Media-src

○ Описывает, откуда мы можем загружать аудио- и видеофайлы

● frame-предки

○ Описывает, какие сайты могут загружать этот сайт в iframe

Для этих директив установлены определенные значения, которые определяют, какие ресурсы могут быть загружены и откуда. Этот список источников можно найти ниже:

● *

○ Загружать ресурсы из любого места

● «нет»

○ Блокировать все

● ‘Самостоятельно’

○ Можно загружать ресурсы только из одного источника

● Данные:

○ Можно загружать ресурсы только из схемы данных (Base64)

● Something.example.com

○ Можно загружать ресурсы только из указанного домена

● Https:

○ Может загружать ресурсы только по протоколу HTTPS

● ‘Unsafe-inline’

○ Разрешает использование встроенных элементов (onclick, теги<script></script>, javascript:,)

● ‘Unsafe-eval’

○ Разрешает динамическую оценку кода (функция eval())

● ‘Sha256-‘

○ Может загружать ресурсы только в том случае, если это соответствует хэшу

● ‘Nonce-‘

○ Позволяет выполнять встроенный скрипт или CSS-код, если тег script содержит атрибут nonce, соответствующий nonce, указанному в заголовке CSP.

Теперь, когда вы знаете о структуре заголовка CSP, давайте рассмотрим пример. Как показано ниже, вы можете видеть, что CSP возвращается в заголовке HTTP-ответа.

default-src ‘none’; base-uri ‘self’; block-all-mixed-content; connect-src ‘self’

uploads.github.com www.githubstatus.com collector.githubapp.com

api.github.com www.google-analytics.com github-cloud.s3.amazonaws.com

github-production-repository-file-5c1aeb.s3.amazonaws.com

github-production-upload-manifest-file-7fdce7.s3.amazonaws.com

github-production-user-asset-6210df.s3.amazonaws.com wss://live.github.com;

font-src github.githubassets.com; form-action ‘self’ github.com gist.github.com;

frame-ancestors ‘none’; frame-src render.githubusercontent.com; img-src ‘self’

data: github.githubassets.com identicons.github.com collector.githubapp.com

github-cloud.s3.amazonaws.com *.githubusercontent.com

customer-stories-feed.github.com spotlights-feed.github.com; manifest-src ‘self’;

media-src ‘none’; script-src github.githubassets.com; style-src ‘unsafe-inline’ github.githubassets.com

Первое, что мы видим, это: default-src ‘none’;. В основном это говорит о том, что нужно блокировать все, если не указано иное. Я также вижу: frame-ancestors ‘none’; . Эта политика не позволит другим сайтам загружать этот сайт в iframe, это устраняет уязвимость для перехвата кликов. Мы также видим:

script-src github.githubassets.com;. Эта политика позволяет сайту загружать файлы javascript только с github.githubassets.com, что, по сути, уничтожает XSS, если мы не сможем найти обходной путь на этом сайте. Существуют и другие политики, которые также можно использовать, чтобы посмотреть, что они делают.

Базовый обход CSP

Существует довольно много способов испортить вашу реализацию CSP. Один из самых простых способов неправильно настроить CSP — использовать опасные значения при настройке политик.

Например, предположим, что у вас есть следующий заголовок CSP:

● по умолчанию -src ‘self’ *

Как вы знаете, политика default-src действует как универсальная политика. Вы также знаете, что * действует как подстановочный знак. Таким образом, эта политика, по сути, предписывает разрешить загрузку любых ресурсов. Это тоже самое, что не иметь заголовка CSP! Вам всегда следует обращать внимание на разрешения с подстановочными знаками.

Давайте рассмотрим другой заголовок CSP:

● script-src ‘unsafe-inline’, ‘unsafe-eval’, ‘self’ данные: https://www.google.com

http://www.google-analytics.com/gtm/js https://*.gstatic.com/feedback/

https://accounts.google.com;

Здесь у нас есть policy script-src, который, как мы знаем, используется для определения того, откуда мы можем загружать файлы javascript. Обычно такие действия, как <IMG SRC=”javascript:alert(‘XSS’);”>, будут заблокированы, но из-за значения «unsafe-inline» они будут выполнены. Это то, на что всегда нужно обращать внимание, поскольку это очень удобно для злоумышленников.

Вы также можете просмотреть данные о значении: это позволит вам загрузить javascript, если у вас есть данные: элемент, как показано ниже: <iframe/src=”данные:текст/html,<загрузка svg=предупреждение(1)>”>.

До сих пор все методы, используемые для обхода CSP, были связаны с неправильной настройкой или злоупотреблением допустимыми функциями CSP. Существует также несколько других методов, которые можно использовать для обхода CSP.

Обход CSP с помощью JSONP

Если вы не знаете, что такое JSONP, возможно, вы захотите ознакомиться с несколькими руководствами по этой теме, но я дам вам краткий обзор. JSONP — это способ обойти политику одинаковых объектов (SOP). Конечная точка JSONP позволяет вставлять полезную нагрузку javascript, обычно в GET укажите параметр “обратный вызов”, и конечная точка вернет вам вашу полезную информацию с типом содержимого JSON, позволяющим обойти SOP. В принципе, мы можем использовать конечную точку JSONP для обработки нашей полезной информации javascript. Вы можете найти пример ниже:

● https://accounts.google.com/o/oauth2/revoke?callback=alert(1337)

Как вы можете видеть выше, на странице отображается функция оповещения.

Опасность возникает, когда в заголовке CSP одна из этих конечных точек включена в белый список в политике script-src. Это означало бы, что мы могли бы загрузить наш вредоносный javascript через конечную точку JSONP в обход политики CSP. Посмотрите на следующий заголовок CSP:

● script-src https://www.google.com http://www.google-analytics.com/gtm/js

https://*.gstatic.com/feedback/ https://accounts.google.com;

Следующее было бы заблокировано CSP:

● http://something.example.com/?vuln_param=javascript:alert (1) ;

Что, если бы мы попробовали следующее:

● http://something.example.com/?vuln_param=https://accounts.google.com/o/oauth2/revoke?callback=alert(1337)

Это могло бы сработать, потому что accounts.google.com разрешено загружать файлы javascript в соответствии с заголовком CSP. Затем мы злоупотребляем функцией JSONP для загрузки нашего вредоносного ПО.

CSP Injection Bypass

Третий тип обхода CSP называется внедрением CSP. Это происходит, когда вводимые пользователем данные отражаются в заголовке CSP. Предположим, у вас есть следующий URL-адрес:

● http://example.com/?vuln=something_vuln_csp

Если ваши вводимые данные отражаются в заголовке CSP, у вас должно получиться что-то вроде этого:

script-src something_vuln_csp;

object-src ‘none’;

base-uri ‘none’;

require-trusted-types-for ‘script’;

report-uri https://csp.example.com;

Это означает, что мы можем контролировать, какое значение будет присвоено значению script-src. Мы можем легко обойти CSP, установив это значение для домена, который мы контролируем.

Резюме

CSP — это заголовок, используемый для управления тем, откуда приложение может загружать свои ресурсы. Это часто используется для устранения уязвимостей, таких как XSS и перехват кликов, но при неправильной настройке это можно легко обойти. Ищите такие вещи, как внедрение CSP или уязвимая конечная точка JSONP. Это может быть простым способом обойти заголовок CSP. Если CSP был настроен неправильно, вы можете использовать функциональность CSP против него самого, чтобы обойти CSP. Например, использование ‘встроенных скриптов’ и подстановочных знаков всегда опасно применительно к политике script-src.

На этом все. Всем хорошего дня!

Цикл статей по Bug Bounty.