В настоящее время я включаю CSP со следующей конфигурацией:
Header set Content-Security-Policy: "default-src 'self' data:; script-src 'self'
'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:"
Похоже, он не делает многого для улучшения реальной безопасности. Реальная проблема связана с встроенным JS. Это может быть отменено в любое время. Разрешение небезопасного inline не защищает нас от того, от чего он защищает нас?
Спасибо за ваше время.
Опция unsafe-inline должна использоваться, когда перемещение или переписывание встроенного кода на вашем текущем сайте не является непосредственной опцией, но вы все еще хотите использовать CSP для управления другими аспектами (такими как object-src, участник js и т.д.). Вы правы в том, что unsafe-inline не обеспечивает большую безопасность, поскольку позволяет выполнять небезопасные скрипты на странице и обработчики событий.
Google CSP Evaluator - отличный инструмент для определения того, является ли ваша политика сильной.
Вариант использования, в котором используется опция unsafe-inline, можно найти в Google Документация веб-разработчика по политике безопасности контента:
Обсуждающий форум свадебного кольца хочет, чтобы все ресурсы загружались только через защищенные каналы, но на самом деле не много писать код; переписывая большие куски программного обеспечения стороннего форума, заполненного до краев встроенным script, и стиль превосходит его возможности. Была бы эффективна следующая политика:
Content-Security-Policy: default-src https:; script-src https: 'unsafe-inline'; style-src https: 'unsafe-inline'Даже если
https:указан вdefault-src, директивы script и style не наследуют этот источник автоматически. Каждая директива полностью перезаписывает значение по умолчанию для этого конкретного типа ресурса.
В то время как я согласен, что это не защищает от многого, классическая эксплуатация XSS - это платформа для браузера, где у вас есть сервер в Интернете, и когда вы получаете отверстие XSS, вы попадаете в "http://bad. example.com/hook.js" > , и теперь вы можете управлять браузером-жертвой с этого сервера. Вы говорите ему открыть скрытое окно, чтобы продолжить доступ, а затем у вас есть двунаправленная связь с их браузером.
CSP с "небезопасным встроенным" по-прежнему потенциально допускает все ту же эксплуатацию (предполагая, что эксплоиты вписываются в пространство, которое вы можете вставить), но немного сложнее подключиться к внешнему миру для получения инструкции или для фильтрации данных.
Это говорит, что я думаю, что по-прежнему можно совершать большинство подобных атак через другие каналы, если вы можете вставить сложную клиентскую часть на веб-страницу.
С моей шляпой злоумышленника на "self unsafe-inline" труднее использовать, чем вообще CSP. Я ожидаю, что инструменты атаки будут адаптироваться к слабым CSP, но это будет означать, что многие распространенные эксплойты сразу же покидают карты или сложнее.