Вопрос или проблема
Мы хотим предотвратить атаки, приходящие из атрибута src “javascript:”, но по-прежнему разрешить инлайн теги скриптов.
В настоящее время единственным вариантом является добавление SHA-хэшей, но инлайн скриптов слишком много, чтобы это сделать.
К сожалению, мы не можем изменить стороннее программное обеспечение, чтобы исправить проверку входных данных, но мы можем добавить к нему заголовки, так как оно размещается на IIS.
Мы пробовали заголовок Content-Security-Policy: “script-src-attr ‘none’; script-src-elem ‘unsafe-inline'”, но это не дало результатов.
Существует ли способ различить инлайн теги скриптов и скрипты с URL src в iframe и img тегах с помощью CSP или каким-либо другим способом?
<html>
<body>
<!-- должен выполниться -->
<script>console.log('RUN: тело тега скрипта');</script>
<!-- не должен выполниться -->
<iframe src="javascript:console.log('XXXX НЕ ВЫПОЛНЯТЬ javascript в iframe:')"></iframe>
<img src="javascript:console.log('XXXX НЕ ВЫПОЛНЯТЬ javascript в img:')" />
</body>
</html>
В настоящее время это невозможно.
Я создал задачу, чтобы запросить это: Возможность блокировать все javascript: URL · Задача #658 · w3c/webappsec-csp
Ответ или решение
К сожалению, в рамках существующих стандартов Content Security Policy (CSP) нет простой возможности разрешить выполнение встроенных скриптов, одновременно блокируя использование javascript:
в атрибутах src
для тегов iframe
и img
.
CSP предоставляет различный уровень контроля над ресурсами, загружаемыми вашим веб-приложением, и хотя вы можете использовать директивы, такие как script-src
, script-src-elem
и другие, они не позволяют добиться желаемого поведения в вашем случае с полным контролем над javascript:
в src
.
Спецификация CSP не поддерживает различие между встроенными скриптами и скриптами, загружаемыми через src
. Поэтому даже если вы установите script-src 'unsafe-inline'
, это не предотвратит исполнение скриптов, использующих javascript:
в src
.
Есть несколько обходных путей, которые можно рассмотреть с точки зрения безопасности вашего приложения:
-
Обработка и фильтрация контента:
- Если у вас есть возможность доработка обработки входных данных, можно написать фильтры, которые удалят или заменят нежелательные URL в самом исходном контенте.
-
Использование дополнительных заголовков:
- Рассмотрите возможность использования заголовков, таких как X-Content-Type-Options и X-XSS-Protection, чтобы повысить уровень безопасности вашего приложения.
-
Переход на другие механизмы защиты:
- Изучите возможность использования других инструментов для предотвращения XSS-атаки, таких как библиотеки защиты от XSS, которые могут обнаруживать и блокировать внедрение скриптов.
-
Сообщество и разработки:
- Вы упомянули, что создали issue в репозитории W3C. Это хорошая практика, чтобы привлечь внимание к проблемы CSP. Поддержите эту инициативу, чтобы сообщество могло работать над улучшением спецификации CSP.
-
Мониторинг и аудит:
- Является полезной практикой проводить регулярный аудит на предмет безопасности, чтобы оценивать, какие ресурсы загружаются, и выявлять потенциальные уязвимости.
В итоге, текущие ограничения CSP затрудняют решение поставленной задачи. Все предложенные методы призваны помочь повысить уровень безопасности вашего приложения в условиях существующих ограничений.