Блог

В настоящее время я определяю политику безопасности контента (CSP), как показано ниже;

 Header set Content-Security-Policy: "default-src 'self' data:; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;"
  

Учитывая приведенное выше определение CSP, у меня есть проблема со встроенным JavaScript, поскольку он может быть перегружен в любое время.

Какой смысл unsafe-inline , если он практически не защищает?

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

CSP Evaluator от Google — это отличный инструмент для определения того, насколько сильна ваша политика.

Пример использования, в котором используется эта unsafe-inline опция, можно найти в документации веб-разработчика Google по политике безопасности контента:

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

 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, но это будет означать, что многие распространенные эксплойты сразу же исчезнут с карты или станут сложнее.