Nginx里容易被忽视的 HTTP 响应头
不知道各位站长们有没有被各类XSS攻击、点击劫持 (ClickJacking) 、 frame 恶意引用等等方式骚扰过，反正是深受其害，百度联盟被封就有这些攻击的功劳在里面。为此一直都在搜寻相关防御办法，至今效果都不是很好，最近发现其实各个浏览器本身提供了一些安全相关的响应头，使用这些响应头一般只需要修改服务器配置即可，不需要修改程序代码，成本很低。至于具体的效果只能是拭目以待了，但是感觉还是有一定的效果的。
而这些HTTP响应头在我们部署 Nginx 的时候经常会被忽略掉，个人感觉这是一个比较严重的“疏忽”，加上还是很有必要的，如果有条件最好是部署一个适合自己站点的X-Content-Security-Policy响应头。
X-Frame-Options 响应头
X-Frame-Options HTTP 响应头是微软提出来的一个HTTP响应头，主要用来给浏览器指示允许一个页面可否在 <frame>, <iframe> 或者 <object> 中展现的标记。网站可以使用此功能，来确保自己网站的内容没有被嵌到别人的网站中去，也从而避免了点击劫持 (ClickJacking) 的攻击。
使用 X-Frame-Options 有三个值:
· DENY
表示该页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。
· SAMEORIGIN
表示该页面可以在相同域名页面的 frame 中展示。
· ALLOW-FROM uri
表示该页面可以在指定来源的 frame 中展示。
如果设置为 DENY，不光在别人的网站 frame 嵌入时会无法加载，在同域名页面中同样会无法加载。另一方面，如果设置为SAMEORIGIN，那么页面就可以在同域名页面的 frame 中嵌套。
PS：目前发现这个HTTP响应头会带来的问题就是百度统计中的“热点追踪(页面点击图）”功能会失效，这也说明百度统计的“热点追踪(页面点击图）”使用的是 frame 嵌入引用网页的形式，这时候大家可以使用 X-Frame-Options 的ALLOW-FROM uri来指定百度统计域名为可 frame 嵌入域名即可。具体在
Nginx里可以采用如下的方式添加响应头：
add_header X-Frame-Options:ALLOW-FROM https://tongji.baidu.com;
add_header X-Frame-Options:SAMEORIGIN;
X-Content-Type-Options响应头
互联网上的资源有各种类型，通常浏览器会根据响应头的Content-Type字段来分辨它们的类型。例如：text/html代表html文档，image/png是PNG图片，text/css是CSS样式文档。然而，有些资源的Content-Type是错的或者未定义。这时，某些浏览器会启用MIME-sniffing来猜测该资源的类型，解析内容并执行。
例如，我们即使给一个html文档指定Content-Type为text/plain，在IE8-中这个文档依然会被当做html来解析。利用浏览器的这个特性，攻击者甚至可以让原本应该解析为图片的请求被解析为JavaScript。在Nginx里通过下面这个响应头可以禁用浏览器的类型猜测行为：
add_header X-Content-Type-Options: nosniff
这个响应头的值只能是nosniff，可用于IE8+和Chrome。
· IE的行为受X-Content-Type-Options的影响，如果Web应用没有返回Content-Type，那么IE9、IE11将拒绝加载相关资源。
如果服务器发送响应头 “X-Content-Type-Options: nosniff”，则 script 和 styleSheet
元素会拒绝包含错误的 MIME 类型的响应。这是一种安全功能，有助于防止基于 MIME 类型混淆的攻击。
X-Content-Security-Policy响应头
W3C 的 Content Security Policy，简称 CSP。顾名思义，这个规范与内容安全有关，主要是用来定义页面可以加载哪些资源，减少 XSS 的发生。
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
如何使用
要使用 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 | 针对 WebFont 的加载策略。 |
| object-src | 'self' | 针对 <object>、 或 <applet> 等标签引入的 flash 等插件的加载策略。 |
| media-src | media.a.com | 针对 <audio> 或 <video> 等标签引入的 HTML 多媒体的加载策略。 |
| frame-src | 'self' | 针对 frame 的加载策略。 |
| sandbox | allow-forms | 对请求的资源启用 sandbox（类似于 iframe 的 sandbox 属性）。 |
| report-uri | /report-uri | 告诉浏览器如果请求的资源不被策略允许时，往哪个地址提交日志信息。 特别的：如果想让浏览器只汇报日志，不阻止任何内容，可以改用 Content-Security-Policy-Report-Only 头。 |
PS:完整的浏览器 CSP 支持情况请移步 CanIUse 。
| 指令值 | 指令示例 | 说明 |
| 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 是远远不够的，不支持全部浏览器是它的硬伤。不过，鉴于低廉的开发成本，加上也没什么坏处。
实际案例
· Google+，使用了这几个本文提到的响应头
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
· Twitter使用了这些
strict-transport-security: max-age=631138519
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block
· PayPal的
X-Frame-Options: SAMEORIGIN
Strict-Transport-Security: max-age=14400
· Facebook则使用了这些（配置了详细的CSP，关闭了XSS保护）
strict-transport-security: max-age=60
x-content-type-options: nosniff
x-frame-options: DENY
x-xss-protection: 0
content-security-policy: default-src *;script-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* chrome-extension://lifbcibllhkdhoafpjfnlhfpfgnpldfl 'unsafe-inline' 'unsafe-eval' https://*.akamaihd.net http://*.akamaihd.net;style-src * 'unsafe-inline';connect-src https://*.facebook.com http://*.facebook.com https://*.fbcdn.net http://*.fbcdn.net *.facebook.net *.spotilocal.com:* https://*.akamaihd.net ws://*.facebook.com:* http://*.akamaihd.net https://fb.scanandcleanlocal.com:*;
PS：Facebook的CSP配置很有参考意义，大家可以根据自己网站的具体情况来整理出适合自己站点的CSP了。
X-XSS-Protection响应头
顾名思义，这个响应头是用来防范XSS的。最早我是在介绍IE8的文章里看到这个，现在主流浏览器都支持，并且默认都开启了XSS保护，用这个header可以关闭它。它有几种配置：
· 0：禁用XSS保护；
· 1：启用XSS保护；
· 1; mode=block：启用XSS保护，并在检查到XSS攻击时，停止渲染页面（例如IE8中，检查到攻击时，整个页面会被一个#替换）；
浏览器提供的XSS保护机制并不完美，但是开启后仍然可以提升攻击难度，总之没有特别的理由，不要关闭它。
Nginx里配置方法如下：
add_header X-Xss-Protection "1; mode=block";
点击劫持（ClickJacking）是一种视觉上的欺骗手段。大概有两种方式，一是攻击者使用一个透明的iframe，覆盖在一个网页上，然后诱使用户在该页面上进行操作，此时用户将在不知情的情况下点击透明的iframe页面；二是攻击者使用一张图片覆盖在网页，遮挡网页原有位置的含义。
