Question

如果外部加载的脚本（在Chrome扩展程序中用于扩充Gmail）尝试发出XHR / AJAX请求，则会失败。

Refused to load the script 'https://<domain-path>.js?' because it violates the following Content Security Policy directive: "script-src 'self' 'unsafe-inline' 'unsafe-eval' https://talkgadget.google.com/ https://www.googleapis.com/appsmarket/v2/installedApps/ https://www-gm-opensocial.googleusercontent.com/gadgets/js/ https://docs.google.com/static/doclist/client/js/ https://www.google.com/tools/feedback/ https://s.ytimg.com/yts/jsbin/ https://www.youtube.com/iframe_api https://ssl.google-analytics.com/ https://apis.google.com/_/scs/abc-static/ https://apis.google.com/js/ https://clients1.google.com/complete/ https://apis.google.com/_/scs/apps-static/_/js/ https://ssl.gstatic.com/inputtools/js/ https://ssl.gstatic.com/cloudsearch/static/o/js/ https://www.gstatic.com/feedback/js/ https://www.gstatic.com/common_sharing/static/client/js/ https://www.gstatic.com/og/_/js/".

因此：http://googleonlinesecurity.blogspot.com/2014/12/reject-unexpected-content-security.html

从这个问题：Gmail Content Security Policy on Chrome extensions

该解决方案适用于将外部加载的脚本注入页面。但是，如果该脚本发出XHR请求，则会以相同的方式阻止它：

工作流程为：

扩展启动gmail.com，将本地文件注入head（preloader.js）
Preloader通过注入标记来加载外部Javascript文件（actual-code.js）。
实际的扩展程序代码会尝试发出AJAX / XHR请求并被Gmail的CSP阻止。

这似乎无法通过更新扩展中的CSP来解决，因为这些策略适用于内容脚本，而不适用于任何手动注入的脚本。

可能的解决方案有缺点： - 在扩展中包含完整代码（更难以保持最新，与扩展版本相关联）

还有其他想法吗？

Answer 1

安全的方法是公开一个＆＃34; API＆＃34;在您的脚本可以使用的扩展中。

任何注入页面的带有标记的脚本都存在于页面的执行上下文中。但是，它与内容脚本共享DOM（根据您的清单可以使用XHR）。

您可以引发自定义DOM事件以请求您的分机执行XHR，并再次传回结果。方法在此处描述：Gmail Extension, sendMessage to background from page context

在外部加载的脚本中制作XHR请求（Gmail，Chrome 39.x，内容安全策略）

1 个答案: