Политика безопасности контента

Расширения, разработанные с помощью API WebExtension, по умолчанию имеют применённую к ним Политику безопасности контента (CSP). Это ограничивает источники, из которых они могут загружать код, такой как <script>, и запрещает потенциально небезопасные практики, такие как использование eval(). В этой статье кратко объясняется, что такое CSP, какова политика по умолчанию и что это значит для расширения, а также как расширение может изменить политику CSP по умолчанию.

Политика безопасности контента (CSP) — это механизм, помогающий предотвратить случайное выполнение вредоносного контента на веб-сайтах. Веб-сайт указывает CSP с помощью HTTP-заголовка, отправляемого сервером. CSP в основном связана с указанием законных источников различных типов контента, таких как скрипты или встроенные плагины. Например, веб-сайт может использовать её для указания того, что браузер должен выполнять JavaScript только, загруженный с самого веб-сайта, а не из других источников. CSP также может указывать браузеру запретить потенциально небезопасные практики, такие как использование eval().

Как и веб-сайты, расширения могут загружать контент из разных источников. Например, всплывающее окно действия браузера задаётся как HTML-документ, и оно может включать JavaScript и CSS из разных источников, как и обычная веб-страница:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
  </head>
  <body>
    <!--Some HTML content here-->
    <!--
      Include a third-party script.
      See also https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity.
    -->
    <script
      src="https://code.jquery.com/jquery-2.2.4.js"
      integrity="sha256-iT6Q9iMJYuQiMWNd9lDyBUStIq/8PuOW33aOqmvFpqI="
      crossorigin="anonymous"></script>

    <!-- Include my popup's own script-->
    <script src="popup.js"></script>
  </body>
</html>

По сравнению с веб-сайтом, расширения имеют доступ к дополнительным привилегированным API, поэтому, если они скомпрометированы вредоносным кодом, риски выше. По этой причине:

расширениям по умолчанию применяется довольно строгая политика безопасности контента. См. политику безопасности контента по умолчанию.
автор расширения может изменить политику по умолчанию, используя ключ content_security_policy в файле manifest.json, но существуют ограничения на разрешённые политики. См. content_security_policy.

Политика безопасности контента по умолчанию

Политика безопасности контента по умолчанию для расширений, использующих Manifest V2, такова:

"script-src 'self'; object-src 'self';"

В то время как для расширений, использующих Manifest V3, политика безопасности контента по умолчанию:

"script-src 'self'; upgrade-insecure-requests;"

Эти политики применяются к любому расширению, которое не задало явно собственную политику безопасности контента, используя ключ content_security_policy в файле manifest.json. Это имеет следующие последствия:

Вы можете загружать только ресурсы <script> и <object>, которые находятся локально в расширении.
Расширению запрещено оценивать строки как JavaScript.
Встроенный JavaScript не выполняется.
WebAssembly по умолчанию использовать нельзя.
Небезопасные сетевые запросы обновляются в Manifest V3.

Расположение ресурсов script и object

В соответствии с CSP по умолчанию вы можете загружать только код, находящийся локально в расширении. CSP ограничивает script-src только безопасными источниками, что охватывает ресурсы <script>, ES6-модули и веб-воркеры. В браузерах, поддерживающих устаревшие плагины, также ограничен object-src директива. Более подробную информацию об object-src в расширениях см. в проблеме WECG Remove object-src from the CSP (at least in MV3).

Например, рассмотрим такую строку в документе расширения:

<script src="https://code.jquery.com/jquery-2.2.4.js"></script>

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

скачать ресурс, упаковать его в расширение и обратиться к этой версии ресурса.
разрешить необходимый удалённый источник, используя ключ content_security_policy или, в Manifest V3, свойство content_scripts.

eval() и аналогичные функции

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

eval("console.log('some output');");

setTimeout("alert('Hello World!');", 500);

const f = new Function("console.log('foo');");

Встроенный JavaScript

Согласно CSP по умолчанию, встроенный JavaScript не выполняется. Это запрещает как JavaScript, размещённый непосредственно в <script> тегах, так и обработчики событий в строчном формате, а значит, следующие действия запрещены:

<script>
  console.log("foo");
</script>

<div onclick="console.log('click')">Click me!</div>

Если вы в настоящее время используете код, подобный <body onload="main()"> для выполнения скрипта после загрузки страницы, используйте вместо этого события DOMContentLoaded или load.

WebAssembly

Расширениям, желающим использовать WebAssembly, необходимо указать 'wasm-unsafe-eval' в директиве script-src.

С Firefox 102 и Chrome 103, 'wasm-unsafe-eval' можно включить в ключ content_security_policy manifest.json для разрешения использования WebAssembly в расширениях.

Расширения Manifest V2 в Firefox могут использовать WebAssembly без 'wasm-unsafe-eval' в своей CSP для обратной совместимости. Однако, такое поведение не гарантируется, см. Firefox bug 1770909. Поэтому расширениям, использующим WebAssembly, рекомендуется объявлять 'wasm-unsafe-eval' в своей CSP.

Для Chrome, расширения не могут использовать WebAssembly в версии 101 или ранее. В 102, расширения могут использовать WebAssembly (то же поведение, что и Firefox 101 и ранее). С версии 103, расширения могут использовать WebAssembly, если они включают 'wasm-unsafe-eval' в content_security_policy в ключе manifest.

Обновление небезопасных сетевых запросов в Manifest V3

Расширения должны использовать https: и wss: при общении с внешними серверами. Чтобы поощрить это как стандартное поведение, CSP по умолчанию Manifest V3 включает директиву upgrade-insecure-requests. Эта директива автоматически обновляет сетевые запросы к http: для использования https:.

Хотя запросы автоматически обновляются, всё равно рекомендуется использовать https:-URL в коде расширения, где это возможно. В частности, записи в разделе host_permissions раздела manifest.json должны начинаться с https:// или *:// вместо только http://.

Расширения Manifest V3, которым нужно выполнять http: или ws: запросы, могут отказаться от этого поведения, переопределив CSP по умолчанию, используя ключ content_security_policy manifest.json с политикой, исключающей директиву upgrade-insecure-requests. Однако, для соответствия требованиям безопасности Политики дополнений, все пользовательские данные должны передаваться безопасно.

CSP для скриптов содержимого

В Manifest V2 скрипты содержимого не имеют CSP. Начиная с Manifest V3, скрипты содержимого используют CSP по умолчанию, как и расширения. В настоящее время невозможно указать отдельную CSP для скриптов содержимого (источник).

Степень, в которой CSP управляет загрузками из скриптов содержимого, варьируется в зависимости от браузера. В Firefox, функции JavaScript, такие как eval, ограничены CSP расширения. Как правило, большинство API, основанных на DOM, подчиняются CSP веб-страницы. В Chrome, многие API DOM покрываются CSP расширения, а не CSP веб-страницы (crbug 896041).

© 2005–2023 MDN contributors.
Licensed under the Creative Commons Attribution-ShareAlike License v2.5 or later.
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_Security_Policy