内容安全政策如何运作？ [英] How does Content Security Policy work?

问题描述

拒绝评估一个字符串

拒绝执行内联脚本，因为它违反了以下内容安全策略指令

拒绝加载脚本

拒绝加载样式表

这是怎么回事？内容安全政策如何运作？如何使用 Content-Security-Policy HTTP标头？

具体来说， p>

1. ...允许多个来源？


2. ...使用不同的指令？


3. ...使用多个指令


4. ...处理端口
...

5. ...处理不同的协议
li>

6. ...允许 file：// 协议？


7. ...使用内联样式，脚本和标记< style> 和< script> ？


8. ...允许 eval（）？

最后：

9. 'self'是什么意思？

解决方案

Content-Security-Policy 标记允许您通过允许您定义资源可以在哪里可以降低 XSS 攻击的风险被加载，阻止浏览器f从任何其他位置加载数据。这使得攻击者更难以向您的网站注入恶意代码。

我的头撞砖墙试图弄清楚为什么我在获得CSP错误后另一个，似乎没有任何简明而明确的指示，说明它是如何工作的。所以我试图简单地解释CSP的一些点，主要集中在我发现很难解决的事情上。为简洁起见，我赢得了' t在每个样本中写满标签。相反，我只会显示内容属性，所以一个示例 content =default-src'self'表示：

 < meta http-equiv =Content-Security-Policycontent =default-src'self > 
  

1。如何允许多个来源？

您可以简单地将您的来源列在空格分隔列表的指令之后：

  content =default-src'self'https://example.com/js/
  

请注意，除特殊之外的参数没有引号，例如'self'。另外，指令后面没有冒号（：）。只是指令，然后是空格分隔的参数列表。

隐式允许低于指定参数的所有内容。这意味着在上面的例子中这些将是有效的来源：

  https://example.com/js/file.js 
 https://example.com/js/subdir/anotherfile.js 
  

这些，然而，这是无效的：

  http://example.com/js/file.js 
 ^ ^ ^^错误的协议
 
 https://example.com/file.js 
 ^^指定路径之上
  

2。如何使用不同的指令，它们各自做什么？

最常见的指令是：

• default-src 加载JavaScript，图片，CSS，字体，AJAX请求等的默认策略


• script-src 为JavaScript文件定义了有效的来源
  
• style-src 定义css文件的有效来源


• img-src 定义图像的有效来源
  
• connect-src 为XMLHttpRequest（AJAX），WebSockets或EventSource定义了有效的目标。如果尝试连接到这里不允许的主机，浏览器将模拟 400 错误

还有其他的，但这些是您最需要的。

3。如何使用多个指令？
$ b 您可以在一个元标签内定义所有指令，方法是用分号（; ）：

  content =default-src'self'https://example.com/js /; style-src'self'
  

4。如何处理端口？

在允许的域之后添加端口号或星号需明确允许除默认端口之外的任何端口：

  content =default-src'self'https://ajax.googleapis.com http://example.com:123/free / stuff /
  

以上将导致：

  https://ajax.googleapis.com:123 
 ^^^^不正确，错误的端口
 
 https：// ajax .googleapis.com  - 确定
 
 http://example.com/free/stuff/file.js 
 ^^不正确，只允许端口123 
 
 http://example.com:123/free/stuff/file.js  - 好的
  

正如我所提到的，您也可以使用星号来显式允许所有端口：

  content =default-src example.com： *
  

5。如何处理不同的协议？

默认情况下，只允许使用标准协议。例如，要允许WebSockets ws：// ，您必须明确地允许它：

  content =default-src'self'; connect-src ws :; style-src'self'
 ^^^ web套接字现在允许在所有域和端口上
  

6。如何允许文件协议 file：// ？

如果您尝试定义它本身不起作用。相反，您可以使用文件系统参数来允许它：

  content =default-src文件系统
  

如何使用内联脚本和样式定义？

除非明确允许，否则不能使用内联样式定义，代码位于< ;脚本> 标签或标签属性，如 onclick 。你允许他们这样做：

  content =script-src'unsafe-inline'; style-src'unsafe-inline' 
  

您还必须明确允许内联，base64编码图像：

  content =img-src data：
  

8。如何让 eval（）？

我相信很多人会说你不会因为'eval是邪恶的'，也是世界即将结束的最可能原因。那些人会错的。当然，你可以通过eval为网站的安全性打出重大漏洞，但它有完全有效的用例。你只需要聪明地使用它。你可以这样做：

  content =script-src'unsafe-eval'
  

9。 'self'是什么意思？

您可以将' self'表示本地主机，本地文件系统或同一主机上的任何内容。这并不意味着任何这些。它意味着具有与定义内容策略的文件相同的方案（协议），相同主机和相同端口的源。通过HTTP为您的站点提供服务？

在大多数示例中，我都使用了'self'因为通常包括它是有意义的，但这绝不是强制性的。如果您不需要它，请将其保留。

但请稍等！我不能只使用 content =default-src *并完成它？

没有。除了明显的安全漏洞之外，这也会让它无法像你期望的那样工作。尽管一些文档声称它允许任何内容，但事实并非如此。它不允许内联或摘要，所以要真正让你的网站变得更加脆弱，你可以使用这个： =default-src *'unsafe-inline''unsafe-eval'


...但我相信你不会的。

进一步阅读：
$ b

http://content-security-policy.com

http://en.wikipedia.org/wiki/Content_Security_Policy

I'm getting a bunch of errors in the developer console:

Refused to evaluate a string

Refused to execute inline script because it violates the following Content Security Policy directive

Refused to load the script

Refused to load the stylesheet

What's this all about? How does Content Security Policy work? How do I use the Content-Security-Policy HTTP header?

Specifically, how to...

1. ...allow multiple sources?
2. ...use different directives?
3. ...use multiple directives?
4. ...handle ports?
5. ...handle different protocols?
6. ...allow file:// protocol?
7. ...use inline styles, scripts, and tags <style> and <script>?
8. ...allow eval()?

And finally:

9. What exactly does 'self' mean?

解决方案

The Content-Security-Policy meta-tag allows you to reduce the risk of XSS attacks by allowing you to define where resources can be loaded from, preventing browsers from loading data from any other locations. This makes it harder for an attacker to inject malicious code into your site.

I banged my head against a brick wall trying to figure out why I was getting CSP errors one after another, and there didn't seem to be any concise, clear instructions on just how does it work. So here's my attempt at explaining some points of CSP briefly, mostly concentrating on the things I found hard to solve.

For brevity I won’t write the full tag in each sample. Instead I'll only show the content property, so a sample that says content="default-src 'self'" means this:

<meta http-equiv="Content-Security-Policy" content="default-src 'self'">

1. How to allow multiple sources?

You can simply list your sources after a directive as a space separated list:

content="default-src 'self' https://example.com/js/"

Note that there are no quotes around parameters other than the special ones, like 'self'. Also, there's no colon (:) after the directive. Just the directive, then a space-separated list of parameters.

Everything below the specified parameters is implicitly allowed. That means that in the example above these would be valid sources:

https://example.com/js/file.js
https://example.com/js/subdir/anotherfile.js

These, however, would not be valid:

http://example.com/js/file.js
^^^^ wrong protocol

https://example.com/file.js
                   ^^ above the specified path

2. How to use different directives, what do they each do?

The most common directives are:

• default-src the default policy for loading javascript, images, CSS, fonts, AJAX requests, etc
• script-src defines valid sources for javascript files
• style-src defines valid sources for css files
• img-src defines valid sources for images
• connect-src defines valid targets for to XMLHttpRequest (AJAX), WebSockets or EventSource. If a connection attempt is made to a host that's not allowed here, the browser will emulate a 400 error

There are others, but these are the ones you're most likely to need.

3. How to use multiple directives?

You define all your directives inside one meta-tag by terminating them with a semicolon (;):

content="default-src 'self' https://example.com/js/; style-src 'self'"

4. How to handle ports?

Everything but the default ports needs to be allowed explicitly by adding the port number or an asterisk after the allowed domain:

content="default-src 'self' https://ajax.googleapis.com http://example.com:123/free/stuff/"

The above would result in:

https://ajax.googleapis.com:123
                           ^^^^ Not ok, wrong port

https://ajax.googleapis.com - OK

http://example.com/free/stuff/file.js
                 ^^ Not ok, only the port 123 is allowed

http://example.com:123/free/stuff/file.js - OK

As I mentioned, you can also use an asterisk to explicitly allow all ports:

content="default-src example.com:*"

5. How to handle different protocols?

By default, only standard protocols are allowed. For example to allow WebSockets ws:// you will have to allow it explicitly:

content="default-src 'self'; connect-src ws:; style-src 'self'"
                                         ^^^ web sockets are now allowed on all domains and ports

6. How to allow the file protocol file://?

If you'll try to define it as such it won’t work. Instead, you'll allow it with the filesystem parameter:

content="default-src filesystem"

7. How to use inline scripts and style definitions?

Unless explicitly allowed, you can't use inline style definitions, code inside <script> tags or in tag properties like onclick. You allow them like so:

content="script-src 'unsafe-inline'; style-src 'unsafe-inline'"

You'll also have to explicitly allow inline, base64 encoded images:

content="img-src data:"

8. How to allow eval()?

I'm sure many people would say that you don't, since 'eval is evil' and the most likely cause for the impending end of the world. Those people would be wrong. Sure, you can definitely punch major holes into your site's security with eval, but it has perfectly valid use cases. You just have to be smart about using it. You allow it like so:

content="script-src 'unsafe-eval'"

9. What exactly does 'self' mean?

You might take 'self' to mean localhost, local filesystem, or anything on the same host. It doesn't mean any of those. It means sources that have the same scheme (protocol), same host, and same port as the file the content policy is defined in. Serving your site over HTTP? No https for you then, unless you define it explicitly.

I've used 'self' in most examples as it usually makes sense to include it, but it's by no means mandatory. Leave it out if you don't need it.

But hang on a minute! Can't I just use content="default-src *" and be done with it?

No. In addition to the obvious security vulnerabilities, this would leave it also won’t work as you'd expect. Even though some docs claim it allows anything, that's not true. It doesn't allow inlining or evals, so to really, really make your site extra vulnerable, you would use this:

content="default-src * 'unsafe-inline' 'unsafe-eval'"

... but I trust you won’t.

Further reading:

http://content-security-policy.com

http://en.wikipedia.org/wiki/Content_Security_Policy

这篇关于内容安全政策如何运作？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！