不知道各位站长们有没有被各类XSS攻击、点击劫持 (ClickJacking1) 、 frame 恶意引用等等方式骚扰过,反正明月是深受其害,百度联盟被封就有这些攻击的功劳在里面。为此明月一直都在搜寻相关防御办法,至今效果都不是很好,最近明月发现其实各个浏览器本身提供了一些安全相关的响应头,使用这些响应头一般只需要修改服务器配置即可,不需要修改程序代码,成本很低。至于具体的效果只能是拭目以待了,但是感觉还是有一定的效果的。

timg (10).jpg

而这些HTTP响应头在我们部署 Nginx 的时候经常会被忽略掉,明月个人感觉这是一个比较严重的“疏忽”,加上还是很有必要的,如果有条件最好是部署一个适合自己站点的X-Content-Security-Policy响应头。

X-Frame-Options 响应头

X-Frame-Options HTTP 响应头是微软提出来的一个HTTP响应头,主要用来给浏览器指示允许一个页面可否在 <frame>, <iframe> 或者 <object> 中展现的标记。网站可以使用此功能,来确保自己网站的内容没有被嵌到别人的网站中去,也从而避免了点击劫持 (ClickJacking1) 的攻击。

使用 X-Frame-Options 有三个值:

  • DENY

表示该页面不允许在 frame 中展示,即便是在相同域名的页面中嵌套也不允许。

  • SAMEORIGIN

表示该页面可以在相同域名页面的 frame 中展示。

  • ALLOW-FROM uri

表示该页面可以在指定来源的 frame 中展示。

如果设置为 DENY,不光在别人的网站 frame 嵌入时会无法加载,在同域名页面中同样会无法加载。另一方面,如果设置为SAMEORIGIN,那么页面就可以在同域名页面的 frame 中嵌套。

PS:目前明月发现这个HTTP响应头会带来的问题就是百度统计中的“热点追踪(页面点击图)”功能会失效,这也说明百度统计的“热点追踪(页面点击图)”使用的是 frame 嵌入引用网页的形式,这时候大家可以使用 X-Frame-OptionsALLOW-FROM uri来指定百度统计域名为可 frame 嵌入域名即可。具体在Nginx里可以采用如下的方式添加响应头:

add_header X-Frame-Options:ALLOW-FROM https://tongji.baidu.com;
add_header X-Frame-Options:SAMEORIGIN;

timg (9).jpg

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-srcCSP 指令,多个指令之间用英文分号分割;'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'针对 AjaxWebSocket 等请求的加载策略。不允许的情况下,浏览器会模拟一个状态为 400 的响。
font-srcfont.a.com针对 WebFont 的加载策略。
object-src'self'针对 <object><embed><applet> 等标签引入的 flash 等插件的加载策略。
media-srcmedia.a.com针对 <audio><video> 等标签引入的 HTML 多媒体的加载策略。
frame-src'self'针对 frame 的加载策略。
sandboxallow-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.comimg-src img.a.com允许加载指定域名的资源。
.a.comimg-src .a.com允许加载 a.com 任何子域的资源。
https://img.comimg-src https://img.com允许加载 img.com 的 https 资源(协议需匹配)。
https: img-srchttps:允许加载 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";


  1. 点击劫持(ClickJacking)是一种视觉上的欺骗手段。大概有两种方式,一是攻击者使用一个透明的iframe,覆盖在一个网页上,然后诱使用户在该页面上进行操作,此时用户将在不知情的情况下点击透明的iframe页面;二是攻击者使用一张图片覆盖在网页,遮挡网页原有位置的含义;
最后修改:2018 年 02 月 01 日
如果觉得我的文章对你有用,请随意赞赏