Анализ уязвимостей стандарта Content Security Policy с целью повышения защиты веб-сайтов

Обеспечение защиты данных в рамках функционирования веб-ресурсов уже давно стало острым вопросом. Реализуется данного рода безопасность различными образами, а одним из актуальных механизмов стал отдельный уровень, именуемый Content Security Policy. Этот механизм направлен на обнаружение и устранение атак, основанных на межсайтовом скриптинге и внедрению данных злоумышленника в передаваемые запросы. Для работы использует ряд директив, позволяющих гибко настроить механизмы защиты. Однако, несмотря на высокий уровень популярности данный стандарт защиты веб-сервисов и приложений обладает рядом недостатков, изучение которых позволит определить способы их устранения для широкого круга специалистов. Однако фактически, несмотря на наличие целого набора директив, обеспечивающих разные направления защиты от инъекции кода, злоумышленники находят методы их обхода. Именно поэтому в рамках данной статьи исследуются данные методы, а также выявляется методика перенаправления запросов, которая ранее нигде не была освещена.

Начать статью стоит с рассмотрения определения атаки типа Stored XSS. Так называют уязвимость в веб-системах, связанная с возможностью внедрения злоумышленником на страницу вредоносного программного кода (чаще всего на JavaScript)

Современные веб-сервисы уже давно реализуются так, чтобы устранить возможность реализации XSS-уязвимостей злоумышленниками. Также в данном направлении работают и разработчики веб-браузеров, которые используют инструменты валидации входной информации, а также политики Same‑Origin Policy (определяет разрешения на доступ к данным для скриптов) и Content Security Policy (определяет перечень доверенных источников скриптов). Однако уязвимости ещё имеют место, и в рамках данной статьи предлагается рассмотреть таковые в составе политики CSP.

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

Стандарт CSP обладает несколькими версиями, которые обеспечивают полный уровень совместимости. Исключение составляет вторая версия стандарта, имеющая ряд несоответствий в плане совместимости с остальными версиями. Однако это все равно позволяет браузерам работать с серверами, используя различные версии стандарта. В случае если сервером не будет предложен заголовок CSP, то браузером будет попросту применена стандартная политика для данного источника

Для того чтобы сформировать перечень доверенных источников, в рамках стандарта CSP на веб-странице должны быть размещены специализированный заголовок Content-Security-Policy и набор директив, к которым относятся:

• img-src – настройка источников для загрузки изображений;

• media-src – настройка источников для загрузки медиаконтента (видео, анимации, аудио);

• script-src – настройка источников для загрузки сценариев и скриптов для веб-страницы;

• frame-src – настройка источников для загрузки веб-элементов;

• default-src – резервная директива. В том случае, если в одной или нескольких директивах, представленных выше, отсутствуют аргументы, то браузер использует источники, указанные в данной директиве

За счет использования представленного перечня директив разработчики могут указать для загрузки домен, поддомен, либо отдельную страницу, а также указать правила взаимодействия. Для этого при описании директивы могут быть использованы две директивы: "none" запрещает, а "self" разрешает использование ресурсов, находящихся на указанном источнике.

Помимо общих правил для отдельных директив существуют собственные правила. Так, существует правило "unsafe-inline", которое разрешает использование JS-скриптов, размещаемых непосредственно в коде веб-страницы. И если данное правило не прописать, то любой скрипт, загруженный не из доверенного источника, будет заблокирован. Правило "unsafe-eval" позволяет разрешить или заблокировать (по умолчанию) выполнение динамического кода в процессе его работы

Для того чтобы получить возможность использования политики CSP, следует выполнить настройку возврата соответствующего заголовка на веб странице. В том случае, если разработчик хочет протестировать политику CSP, существует другая директива – Content-Security-Policy-Report-Only. При её использовании не будет происходить блокировка загрузки скриптов, однако все зафиксированные нарушения и отклонения будут внесены в специальные отчеты, которые отправляются системному администратору.

Однако, несмотря на, казалось бы, простоту реализации, и при этом возможности гибкой настройки разрешенных источников для веб-ресурсов, CSP имеет уязвимости, посредством которых злоумышленники могут реализовать угрозу XSS

Одна из выявленных уязвимостей завязана на использовании правила "unsafe-inline" в директиве "script-src". Казалось бы, данная директива позволяет ограничить возможности передачи конфиденциальной информации на сторону. В том случае, если данная директива не включена, то разработчикам необходимо вручную внести огромнейший список ресурсов, на которые эти данные могут быть переданы. А некорректная настройка данной директивы может привести к ограниченной работоспособности приложения. Именно по этой причине разработчики зачастую используют данную директиву, считая, что она позволит обеспечить защиту от передачи информации на другие ресурсы, однако на практике это не всегда так.

В результате проведенного исследования было установлено, что если использовать метод редиректа, то будет получена возможность получения всех необходимых параметров. Для этого необходимо сформировать URL-ссылку, в которой в составе GET-запроса будут указаны необходимые параметры, которые требуется получить. Пример такого запроса на рисунке 1:

Рисунок 1 - Процесс формирования URL-ссылки и передача конфиденциальных данных на сервер-перехватчик

DOI:10.60797/itech.2025.5.1.1

Представленная выше ссылка позволит получить cookie сессии, однако данный вариант обладает определенным недостатком – атака предполагает переадресацию пользователя на сервер-перехватчик, что по итогу может нарушить работу атакуемого веб-сайта. Для устранения этого недостатка подход к реализации перехвата данных необходимо доработать. Сперва необходимо реализовать сервер-перехватчик таким образом, чтобы он принимал данные не возвращая ответ и удерживая соединение открытым. Затем произвести переход по ссылке на сервер-перехватчик с указанием необходимых для перехвата параметров, после чего вызвать процедуру "window.stop", который отменит перенаправление на сервер-перехватчик и сделает атаку незаметным для пользователя.

Визуально ход перехвата с применением данного метода представлен на рисунке 2 и может быть описан тремя этапами.

Рисунок 2 - Процесс реализации XSS атаки на страницу, использующую CSP-директиву "unsafe-inline"

DOI:10.60797/itech.2025.5.1.2

На первом шаге выполняется переадресация на указанный сервер sleep-sniffer.com с отправкой указанных атрибутов сессии. При этом на странице отображается индикатор загрузки страницы, то есть пользователь считает, что происходит загрузка страницы и ожидает завершения данного процесса. На втором шаге происходит получение запроса сервером-перехватчиком, он сохраняет полученные в составе запроса параметры, а далее удерживает соединение открытым, при этом не отправляя ответ. Особенностью данного метода является тот факт, что в момент ожидания ответа на запрос браузер считает, что страница работает нормально, все скрипты на ней выполняются, а пользователь видит индикатор загрузки и ожидает её завершения. По истечении трех секунд происходит выполнение setTimeout. Это будет переходом на третий шаг – при выполнении метода window.stop происходит отмена загрузки абсолютно всех ресурсов – мультимедиа, шрифты, стили оформления и прочего. При этом не выполненные запросы будут просто отменены. То есть веб-страница будет работать далее, все необходимые данные будут переданы в составе запроса на сервер sleep-sniffer.com, а пользователь не будет ничего подозревать. Для реализации метода перехвата данных с использованием редиректа была написана утилита, окно которой представлено на рисунке 3

[3]

. Она позволяет указать состав параметров, которые будут переданы в рамках запроса, а также адреса атакуемой страницы и сервера-перехватчика.

Рисунок 3 - Окно утилиты, реализующей запросы с редиректом различных наборов данных [3]

DOI:10.60797/itech.2025.5.1.3

Для того чтобы устранить описанную возможность редиректа с запросом необходимых параметров в CSP, была добавлена директива "navigate-to", которая позволяет указать перечень внешних источников, на которые разрешен редирект с текущей страницы. С одной стороны, она позволяет задать список доменов или адресов, на которые возможно выполнение запросов. С другой – реализация подобного списка требует колоссальных затрат на формирование данного перечня, а также будет приводить к тому, что этот перечень необходимо будет постоянно актуализировать. По этой причине единственным способом обеспечения высокого уровня безопасности будет отказ от использования директивы unsafe-inline и внедрение более эффективной политики CSP, несмотря на все требуемые для этого трудовые и финансовые затраты.

Стандарт CSP включает множество директив и их разнообразные конфигурации, что в ряде случаев может создавать уязвимости, посредством которых злоумышленники могут реализовать угрозу XSS

• внедрение скрипта посредством использования механизмов загрузки файлов;

• внедрение скрипта с использованием публичной CDN;

• внедрение скрипта посредством использования механизма Third-Party EndPoints + JSONP;

• внедрение скрипта с использованием процедур Angular;

Однако данные методы предполагают только внедрение кода на веб-страницу, что не решает проблему передачи конфиденциальных данных со страницы на сервер атакующего. Как и в случае с включенной опцией unsafe-inline, будет действовать ограничение, которое разрешает коммуникацию только с доверенными веб-ресурсами, что препятствует отправке данных со страницы на сервер атакующего. В таком случае можно использовать представленный выше метод в сочетании с другими известными методиками обхода стандарта CSP для обхода данного ограничения.

В результате использования любой из перечисленных уязвимостей злоумышленники получают возможность перехвата различного рода информации, в том числе и данные для авторизации. А их комбинация расширяет возможные методики реализации XSS-атак, и добавляет работы специалистам по безопасности.

Подытоживая, следует отметить тот факт, что несмотря на наличие механизма CSP, направленного на защиты от инъекций программного кода в веб-страницу, качество его работы в большинстве случае оставляет желать лучшего, а злоумышленники находят все новые и новые способы его обхода. В рамках исследования был продемонстрирован существующий критический риск использования директивы unsafe-inline. По этой причине единственным способом обеспечения высокого уровня безопасности будет отказ от использования директивы unsafe-inline и внедрение более эффективной политики CSP, несмотря на все требуемые для этого трудовые и финансовые затраты.