HTTP Security Headers 说明

简单说明一下相关header

HTTP Security Headers的内容

X-XSS-Protection

Content Security Policy

HTTP Strict Transport Security(HSTS)

HTTP Public Key Pinning(HPKP)

X-Frame-Options

X-Content-Type-Options

Referer-Policy

Cookie Options

X-Download-Options

X-Permitted-Cross-Domain-Policies

1. X-XSS-Protection

用于处理跨站脚本攻击 (XSS)。

可选值：

0：禁止XSS过滤
1：启用XSS过滤。 如果检测到跨站脚本攻击，浏览器将清除页面中不安全的部分，但页面仍然可以访问。
1;mode=block：启用XSS过滤。 如果检测到攻击，浏览器将直接阻止页面加载。

HTTP X-XSS-Protection 响应头是 Internet Explorer，Chrome 和 Safari 的一个特性，当检测到跨站脚本攻击 (XSS)时，浏览器将停止加载页面。
浏览器提供的XSS保护机制并不完美，但是开启后仍然可以提升攻击难度，总之没有特别的理由，不要关闭它。

2. Content Security Policy

内容安全策略可以认为是X-XSS-Protection的高级版本。尽管X-XSS-Protection能阻止来自请求的脚本，但是它不能阻止一些XSS攻击，如在你服务器上面存储恶意脚本或者使用恶意脚本加载额外的资源。
CSP提供了一种语言 来定义浏览器能加载来自哪的资源。你能以非常详细的方式来列出原始的脚本、图片、字体和样式等的白名单列表。你还能使用哈希和特征来比较任何加载的资源。

虽然它不能阻止所有的XSS攻击，但是它是缓解XSS攻击的一个重要的措施，并且是深度防御的重要的一个环节。

3. HTTP Strict Transport Security(HSTS)

当我们想与一些人安全通信时，我们面对了两个问题。第一个问题是隐私：我们想确保我们发送的消息只能接收者看到。另一个问题是认证：我们如何知道接收者是他们自己说的那个人？

HTTPS使用加密解决了第一个问题，但是还有个认证问题（稍后详述，参见Public Key Pinning）。HSTS头解决了元问题：你如何知道与你通信的人是否支持加密？

HSTS缓解了一种称为sslstrip的攻击。假设你使用的是恶意攻击者控制的WIFI路由器提供的网络。攻击者可以禁用你和你访问的网站之间的加密机制。即使你访问的网站只能通过HTTPS访问，攻击者还是可以使用中间人攻击HTTP流量，来使得网站看起来工作在未加密的HTTP上。不需要SSL证书，只要禁用加密就可以。

通过让你的浏览器知道它必须总是使用加密访问网站，Strict-Transport-Security头解决了这个问题，除非你的浏览器看到了HSTS头并且没有过期，否则将无法访问未加密的网站，并且如果不经过HTTPS则会出错。

HSTS头的一个缺点是，它允许使用一种聪明的技术来创建supercookies来作为用户的指纹。作为一个网站的运营者，你可能已经有些方式跟踪了你的用户，但是尝试只使用HSTS是更好的方式并且不使用supercookies。

指告诉浏览器自动从HTTP切换到HTTPS(当然，站点得支持HTTPS)。

举例说明，如下图(nginx 将http重定向到https)：

左边没加HSTS配置，301正常重定向，耗时 80ms ;

右边配置了HSTS，浏览器利用cache，直接将HTTP转成了HTTPS，耗时 2ms，免去了重定向过程。

状态从 301 变成了 307 Internal Redirect 即浏览器内部跳转。

4. HTTP Public Key Pinning(HPKP)

上面描述的HSTS头是被设计来确保所有的网站连接都是加密的。然而，它没有指出使用的关键点。
网站的信任是基于CA模型的。你的浏览器和操作系统绑定一些受信任的证书颁发机构的公钥，这些机构通常是专门的公司或者国家地区。当一个CA向你的域名颁发证书后，意味着信任这个CA的任何人都将自动信任使用这个证书加密的SSL流量。这些CA负责验证你拥有的域（可以是发送邮件、请求你托管文件或调查你的公司）。

两个CA给两个不同的人颁发同一个域名的证书，浏览器将信任这两个CA。这就导致了一个问题，尤其是因为CAs可能被攻击。这允许攻击者使用MiTM攻击他们想攻击的域名，即使那个域名使用了SSL和HSTS，也是一样。

HPKP头试着缓解这个问题。这个头让你绑定一个证书。当一个浏览器第一次看见这个头，它将保存这个证书。当每个请求达到max-age，除非从服务器发送的证书链中至少有一个指纹记录，否则浏览器将失败。

和上述的HSTS很像，HPKP头也有隐私影响。这些在它的RFC中有描述。
是否该使用它？

可能不需要。

HPKP是一个非常非常锋利的尖刀。考虑到这个：如果你绑定了错误的证书，或者你丢失了密钥，或者某些事出错了，你将阻止你的用户访问你的网站。你能做的只是等待绑定过期。

5. X-Frame-Options

X-Frame-Options 用来告诉浏览器，页面能不能以 frame、 iframe、 object 形式嵌套在其他站点中，用来避免点击劫持(clickjacking)攻击。例如用下面代码将百度以 iframe 嵌入到自己的站点，然后监听 iframe 事件做些其他事情，用户如果不看URL估计以为自己在用百度。

<iframe src="https://www.baidu.com/" width="100%" height="100%" frameborder="no"></iframe>

可选值：

DENY：页面不允许在 frame 中展示
SAMEORIGIN：same origin，页面可以在相同域名页面的 frame 中展示
ALLOW-FROM uri：页面可以在指定来源的 frame 中展示

6. X-Content-Type-Options

X-Content-Type-Options 用来提示客户端一定要遵循在 Content-Type 首部中对 MIME 类型 的设定，而不能对其进行修改，用于禁用了客户端的 MIME 类型嗅探行为。

当资源缺失 MIME 类型或设置了错误的 MIME 类型时，浏览器可能会通过查看资源来进行MIME嗅探。简单来说，就是如果浏览器不确定资源是什么，就会看看资源的内容，X-Content-Type-Options 就是让浏览器不要干这个事情。

X-Content-Type-Options: nosniff;

7. Referrer-Policy

Referrer-Policy: "no-referrer" 
Referrer-Policy: "no-referrer-when-downgrade" 
Referrer-Policy: "origin" 
Referrer-Policy: "origin-when-cross-origin"
Referrer-Policy: "same-origin" 
Referrer-Policy: "strict-origin" 
Referrer-Policy: "strict-origin-when-cross-origin" 
Referrer-Policy: "unsafe-url"

Referer 是 HTTP 请求header 的一部分，当浏览器（或者模拟浏览器行为）向web 服务器发送请求的时候，头信息里有包含 Referer 。比如我在www.google.com 里有一个www.baidu.com 链接，那么点击这个www.baidu.com ，它的header 信息里就有：

Referer=http://www.google.com

由此可以看出来吧。它就是表示一个来源。

Referer头对于分析非常有用，但是对于隐私是件坏事。有时网站会认为一直发送它不是个好主意。

直接在浏览器的地址栏中输入一个资源的URL地址，那么这种请求是不会包含 Referer 字段的，因为这是一个“凭空产生”的 HTTP 请求，并不是从一个地方链接过去的。

Referer的作用？

7.1 防盗链

我们在www.google.com里有一个www.baidu.com链接，那么点击这个www.baidu.com，它的header信息里就有：

Referer=http://www.google.com

那么可以利用这个来防止盗链了，比如我们只允许我们自己的网站访问我自己的图片服务器，那我的域名是www.google.com，那么图片服务器每次取到Referer来判断一下是不是我自己的域名www.google.com，如果是就继续访问，不是就拦截。

7.2 防止恶意请求

比如静态请求是*.html结尾的，动态请求是*.shtml，那么由此可以这么用，所有的*.shtml请求，必须 Referer 为我自己的网站。

Referer=http://www.google.com

8. Cookie Options

Set-Cookie: <key>=<value>; Expires=<expiryDate>; Secure; HttpOnly; SameSite=strict

这不是个安全的头，但是有3个不同的选项你应该注意：

Cookies标记为Secure将只能通过HTTPS提供服务。这阻止了一些人在MiTM攻击中读取cookies，它可以强制浏览器访问一个指定的网页。

HttpOnly是一个误称，并且和HTTPS无关。Cookies标记为HttpOnly将阻止在javascript中访问。因此如果有XSS缺陷，攻击者不能立即偷到cookies。

SameSite帮助防御CSRF攻击。这种攻击是用户可能在访问不同的网站，无意中欺骗他们对你的网站发出请求，例如，用于GET请求的图片，或者使用javascript提交POST请求，通常使用CSRF令牌来防御这种攻击。Cookie被标记为SamSite将不会发送到不同的站点。

它有两种模式，lax和strict。Lax模式允许cookie作为GET请求的顶层内容被发送（例如你点击一个链接）。Strict不发送任何第三方的cookies。

是否应该使用它？

绝对应该设置Secure和HttpOnly。不幸的是，SameSite cookies只在Chrome和Opera中提供，因此现在可以忽略他们。

9. X-Download-Options

用于设置直接打开用户下载的文件。

X-Download-Options: noopen

• noopen 用于指定IE 8以上版本的用户不打开文件而直接保存文件。在下载对话框中不显示“打开”选项。

10. X-Permitted-Cross-Domain-Policies

用于指定当不能将”crossdomain.xml”文件（当需要从别的域名中的某个文件中读取 Flash 内容时用于进行必要设置的策略文件）放置在网站根目录等场合时采取的替代策略。

X-Permitted-Cross-Domain-Policies: master-only

master-only 只允许使用主策略文件（/crossdomain.xml）