如下是一个典型的安全响应头,
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
这些都是什么东西?为什么我们需要这些……嗯……看起来很拉风的玩意?我们逐一解释一下,
Cache Control
当一个合法用户浏览了授权页面之后退出,一个能共享此终端浏览器的恶意用户可以通过浏览器的历史看到被缓存的页面。为了消解这种漏洞,你需要在包含敏感信息的页面的响应头里插入
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Content Type Options
一直以来,浏览器包括IE都试图用内容嗅探的方式来猜测content type。对于没有指定content type的资源这能帮助浏览器提升用户体验。比如,浏览器遇到一个没有指定content type的javascript,它能正确辨别类型并执行之。这固然有其好处,但是也带来了安全问题。一个恶意用户可以利用某些支持多content type的文件实施XSS攻击。比如,某些网站可能允许用户提交postscript文档并浏览它们,恶意用户就可以创建一个既是postscript同时也是javascript的文档来执行XSS的playload。为了消解这种漏洞,你需要在响应头插入
X-Content-Type-Options: nosniff
HTTP Strict Transport Security (HSTS)
你在访问银行站点的时候是输入mybank.example.com 还是输入 https://
mybank.example.com呢?如果是前者,你可能会受到中间人攻击(Man in the
Middle attacks)。即便银行站点把你的请求重定向到 https://mybank.example.com,攻击者还是还是可能截获最初的HTTP请求窃取你的认证信息并伪造一个假的响应给你(以后有机会再详述中间人攻击吧)。
鉴于很多用户都不输入协议名,加入 HTTP Strict Transport Security (HSTS) 就有其必要了。一旦响应头里有HSTS,浏览器就知道.mybank.example.com 必须被解释成https://mybank.example.com. 这样就大大防御了中间人攻击。加入下面的响应头是告诉浏览器要把站点在一年内作为HTTPS的host,并且对其子域也同等对待。
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options
允许你的页面被潜入到别的页面常常很不安全。比如,一个精心设计的小游戏页面,可能让你点击了转账或者授权等你本不想点按钮。这种攻击叫clickjacking,Google一下能找到很多非常有画面感的示例,请自行搜索,今天改版第一天,我来个100%的原创,就不贴人家的示例图。
为了消解这种漏洞,以前的做法是一种叫frame breaking script的技巧(以下引自OWASP)
First apply an ID to the style element itself:
And then delete that style by its ID immediately after in the script:
(引文结束)
但这只是因为早期浏览器不支持X-Frame-Options, 如今你只需在Header里加入,
X-Frame-Options: DENY
或者
X-Frame-Options: SAMEORIGIN
X-XSS-Protection
有些浏览器,比如Chrome和IE但不包括Fireforx,支持内置的反射型XSS检测,当然,这不是说你因此可以高枕无忧,这只是应用自己防御XSS的一个补充。这种内置过滤器是默认打开的,加X-XSS-Protection头只是为了告诉浏览器再发现XSS攻击之后该怎么做。比如可以让浏览器尝试修复并仍然渲染安全的部分,或者直接阻止所有内容,推荐的方式是后者。这时你需要在响应头里加入
X-XSS-Protection: 1; mode=block
以上。
领取专属 10元无门槛券
私享最新 技术干货