简单说明一下相关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)