Skip to content Skip to main navigation Skip to footer

Linux

Linux:HTTP 的内容安全策略(CSP)

本文介绍的是W3C的Content Security Policy,简称CSP。顾名思义,这个规范与内容安全有关,主要是用来定义页面可以加载哪些资源,减少XSS的发生。

Linux:HTTP 的内容安全策略(CSP)
Linux:HTTP 的内容安全策略(CSP)

Chrome扩展已经引入了CSP,通过manifest.json中的content_security_policy字段来定义。一些现代浏览器也支持通过响应头来定义CSP。下面我们主要介绍如何通过响应头来使用CSP,Chrome扩展中CSP的使用可以参考Chrome官方文档

浏览器兼容性

早期的Chrome是通过X-WebKit-CSP响应头来支持CSP的,而firefox和IE则支持X-Content-Security-Policy,Chrome25和Firefox23开始支持标准的的Content-Security-Policy,见下表。

响应头 Chrome Firefox Safari IE
Content-Security-Policy 25+ 23+
X-Content-Security-Policy 4.0+ 10.0(有限的)
X-Webkit-CSP 14+ 6+

完整的浏览器CSP支持情况请移步CanIUse

如何使用

要使用CSP,只需要服务端输出类似这样的响应头就行了:

Content-Security-Policy: default-src 'self'

default-src是CSP指令,多个指令之间用英文分号分割;’self’是指令值,多个指令值用英文空格分割。目前,有这些CSP指令:

指令 指令值示例 说明
default-src ‘self’ cnd.a.com 定义针对所有类型(js、image、css、web font,ajax请求,iframe,多媒体等)资源的默认加载策略,某类型资源如果没有单独定义策略,就使用默认的。
script-src ‘self’ js.a.com 定义针对JavaScript的加载策略。
style-src ‘self’ css.a.com 定义针对样式的加载策略。
img-src ‘self’ img.a.com 定义针对图片的加载策略。
connect-src ‘self’ 针对Ajax、WebSocket等请求的加载策略。不允许的情况下,浏览器会模拟一个状态为400的响应。
font-src font.a.com 针对Web Font的加载策略。
object-src ‘self’ 针对等标签引入的flash等插件的加载策略。
media-src media.a.com 针对
frame-src ‘self’ 针对frame的加载策略。
sandbox allow-forms 对请求的资源启用sandbox(类似于iframe的sandbox属性)。
report-uri /report-uri 告诉浏览器如果请求的资源不被策略允许时,往哪个地址提交日志信息。 特别的:如果想让浏览器只汇报日志,不阻止任何内容,可以改用Content-Security-Policy-Report-Only头。

指令值可以由下面这些内容组成:

指令值 指令示例 说明
  img-src 允许任何内容。
‘none’ img-src ‘none’ 不允许任何内容。
‘self’ img-src ‘self’ 允许来自相同来源的内容(相同的协议、域名和端口)。
data img-src data 允许data:协议(如base64编码的图片)。
www.a.com img-src img.a.com 允许加载指定域名的资源。
*.a.com img-src *.a.com 允许加载a.com任何子域的资源。
https://img.com img-src https://img.com 允许加载img.com的https资源(协议需匹配)。
https: img-src https: 允许加载https资源。
‘unsafe-inline’ script-src ‘unsafe-inline’ 允许加载inline资源(例如常见的style属性,onclick,inline js和inline css等等)。
‘unsafe-eval’ script-src ‘unsafe-eval’ 允许加载动态js代码,例如eval()。

从上面的介绍可以看到,CSP协议可以控制的内容非常多。而且如果不特别指定’unsafe-inline’时,页面上所有inline的样式和脚本都不会执行;不特别指定’unsafe-eval’,页面上不允许使用new Function,setTimeout,eval等方式执行动态代码。在限制了页面资源来源之后,被XSS的风险确实小不少。

当然,仅仅依靠CSP来防范XSS是远远不够的,不支持全部浏览器是它的硬伤。不过,鉴于低廉的开发成本,加上也没什么坏处。如果担心影响面太大,也可以像下面这样,仅收集不匹配规则的日志,先观察下:

Content-Security-Policy-Report-Only: script-src 'self'; report-uri http://test/

这样,如果页面上有inline的JS,依然会执行,只是浏览器会向指定地址发送一个post请求,包含这样的信息:

{"csp-report":{"document-uri":"http://test/test.php","referrer":"","violated-directive":"script-src 'self'","original-policy":"script-src 'self'; report-uri http://test/","blocked-uri":""}}

 

来源:http://imququ.com/post/content-security-policy-reference.html

Linux:一些安全相关的 HTTP 响应头

现代浏览器提供了一些安全相关的响应头,使用这些响应头一般只需要修改服务器配置即可,不需要修改程序代码,成本很低。本文介绍一些这样的响应头:

Linux:一些安全相关的 HTTP 响应头
Linux:一些安全相关的 HTTP 响应头

1. Strict-Transport-Security

HTTP Strict Transport Security,简称为HSTS。它允许一个HTTPS网站,要求浏览器总是通过HTTPS来访问它。现阶段,除了Chrome浏览器,Firefox4+,以及Firefox的NoScript扩展都支持这个响应头。

我们知道HTTPS相对于HTTP有更好的安全性,而很多HTTPS网站,也可以通过HTTP来访问。开发人员的失误或者用户主动输入地址,都有可能导致用户以HTTP访问网站,降低了安全性。一般,我们会通过Web Server发送301/302重定向来解决这个问题。现在有了HSTS,可以让浏览器帮你做这个跳转,省一次HTTP请求。另外,浏览器本地替换可以保证只会发送HTTPS请求,避免被劫持。

要使用HSTS,只需要在你的HTTPS网站响应头中,加入下面这行:

strict-transport-security: max-age=16070400; includeSubDomains

includeSubDomains是可选的,用来指定是否作用于子域名。支持HSTS的浏览器遇到这个响应头,会把当前网站加入HSTS列表,然后在max-age指定的秒数内,当前网站所有请求都会被重定向为https。即使用户主动输入http://或者不输入协议部分,都将重定向到https://地址。

Chrome内置了一个HSTS列表,默认包含Google、Paypal、Twitter、Linode等等服务。我们也可以在Chrome输入chrome://net-internals/#hsts,进入HSTS管理界面。在这个页面,你可以增加/删除/查询HSTS记录。例如,你想一直以https访问某网址,通过“add Domain”加上去就好了。查看Chrome内置的全部HSTS列表,或者想把自己的网站加入这个列表,请点这里

2. X-Frame-Options

X-Frame-Options,已经转正为Frame-Options,但现阶段使用最好还是带上X-。Chrome4+、Firefox3.6.9+、IE8+均支持,详细的浏览器支持情况看这里。使用方式如下:

x-frame-options: SAMEORIGIN

这个响应头支持三种配置:

  • DENY:不允许被任何页面嵌入;
  • SAMEORIGIN:不允许被本域以外的页面嵌入;
  • ALLOW-FROM uri:不允许被指定的域名以外的页面嵌入(Chrome现阶段不支持);

如果某页面被不被允许的页面以