CSP: Разрешить встроенные скрипты, блокируя javascript: в src iframe

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

Мы хотим предотвратить атаки, приходящие из атрибута 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.

Есть несколько обходных путей, которые можно рассмотреть с точки зрения безопасности вашего приложения:

  1. Обработка и фильтрация контента:

    • Если у вас есть возможность доработка обработки входных данных, можно написать фильтры, которые удалят или заменят нежелательные URL в самом исходном контенте.
  2. Использование дополнительных заголовков:

    • Рассмотрите возможность использования заголовков, таких как X-Content-Type-Options и X-XSS-Protection, чтобы повысить уровень безопасности вашего приложения.
  3. Переход на другие механизмы защиты:

    • Изучите возможность использования других инструментов для предотвращения XSS-атаки, таких как библиотеки защиты от XSS, которые могут обнаруживать и блокировать внедрение скриптов.
  4. Сообщество и разработки:

    • Вы упомянули, что создали issue в репозитории W3C. Это хорошая практика, чтобы привлечь внимание к проблемы CSP. Поддержите эту инициативу, чтобы сообщество могло работать над улучшением спецификации CSP.
  5. Мониторинг и аудит:

    • Является полезной практикой проводить регулярный аудит на предмет безопасности, чтобы оценивать, какие ресурсы загружаются, и выявлять потенциальные уязвимости.

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

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

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