它曾是世界性图书馆梦的开始,如今它是全球知识的汇集地,它是目前最流行的,人们将应用都部署之上的万维网。php
它是敏捷的表明,它不是单一的实体,它由客户端和服务端组成,它的功能在不断地强大,它还有标准。html
虽然愈来愈多的解决方案很是适用于发现什么可行,什么不可行,但它几乎没有一致性,没有易于应用的编程模型。俗话说的好:事情越简单,越安全。简单的事物很难有像XSS,CSRF或点击挟持的漏洞。html5
因为HTTP是一个可扩展的协议,各浏览器厂商都率先推出了有效的头部,来阻止漏洞利用或提升利用漏洞的难度。了解它们是什么,掌握如何应用,能够提升系统的安全性。git
怎么才能尽量不遭受XSS攻击呢?若是有人在你的服务器上写了以下代码浏览器可能不去解析?<script>alert(1);</script>,github
下面是内容安全规范中的说明。web
添加内容安全规范头部并赋以适当的值,能够限制下面属性的来源:chrome
须要特别指定的:django
这就意味着脚本文件只能来自当前文件或apis.google.com(谷歌的JavaScript CDN)编程
另外一个有用的特性就是你能够自动应用 沙盒模式 于整个站点。若是你想试一试效果,你能够用“Content-Security-Policy-Report-Only”头部运行一下,让浏览器返回一个你选的URL。推荐阅读一下HTML5Rocks上的一篇CSP的介绍。segmentfault
遗憾的是IE仍是只支持沙盒模式,而且用的是“X”前缀。安安卓它支持最新的4.4版。
固然,它也不是万能的,若是你动态的产生一个JavaScript,黑客仍是能把恶意JS植入你的服务器中。包含它不会产生危害,在Chrome、 Firefox 和 iOS都能保护用户。
Unnamed QQ Screenshot20140225201216
在哪还能学到更多它的知识呢?
HTML5Rocks 有不错的关于它的介绍。W3C 规范也是个不错的选择。
它能阻止点击挟持攻击,只需一句:
X-Frame-Options: DENY
这可以使浏览器拒绝请求该页的数据。 它的值还有“SAMEORIGIN”,可容许同一源的数据。以及“ALLOW FROM http://url-here.example.com”,它可设置源(IE不支持)。
一些厂商不支持这个头部,它可能会被整合到Content-Security-Policy 1.1。但到目前,没人给出足够的理由说不能使用它。
IE | Firefox | Chrome | iOS Safari | Android Browser |
---|---|---|---|---|
8+ | 3.6.9+ | 4.1.249+ | ? | ? |
(数据来源 Mozilla Developer Network)
没有多少要学,想了解更多,可访问 Mozilla Developer Network 上关于此问题的文章。Coding Horror 上也有比较不错的文章。
让用户上传文件具备危险性,服务上传的文件危险更大,并且很难得到权限。
浏览器进行二次猜想服务的Content-Type并不容易,即便内容是经过MIME嗅探获取的。
X-Content-Type-Options头容许你更有效的告知浏览器你知道你在作什么,当它的值为“nosniff”是才代表Content-Type是正确的。
GitHub 上应用了这一头部,你也能够试试。
虽然这取决于你用户,他们占你正保护的访客的65%,但这个头部只在IE和Chrome中有用。
IE | Firefox | Chrome | iOS Safari | Android Browser |
---|---|---|---|---|
8+ | - (bug 471020) | 1+ | - | - |
FOX IT上有一篇关于MIME嗅探的优秀文章:MIME 嗅探: 特性仍是漏洞? IT Security Stackexchange上也有个专题:X-Content-Type-Options真能防止内容嗅探攻击吗?
个人在线银行使用的是HTTPS来保证真实性(我确实链接到了本身的银行)及安全性(传输过程进行加密)的。然而,这仍是有问题的…
当我在地址栏中输入”onlinebanking.example.com”时,默认使用的是简单的HTTP。只有当服务器重定向到用户时,才使用能提供安全的HTTPS(理论上并不安全,但实际上很好用)。偏巧的是重定向的过程会给黑客提供中间人攻击。为了解决这一问题,Strict-Transport-Security头部应运而生。
HTTP的Strict-Transport-Security(HSTS)头部强制浏览器使用HTTPS在指定的时候。好比说,若是你进入 https://hsts.example.com,它会返回这样的头部:
Strict-Transport-Security: max-age=31536000; includeSubDomains
即便敲入http://hsts.example.com,浏览器也会自动变成https://hsts.example.com. 只要HSTS头部一直有效,浏览器就会默认这么作。在上例的状况下,从发送头部到获得响应,有效性可保持1年。因此,若是我2013年1月1日访问了某网站,知道2014年1月1日,浏览器都会使用HTTPS。但若是我2013年12月31日又访问了一次,那有效期也会变成2014年12月31日。
目前它仅适用于Chrome和Firefox,IE用户依然存在此漏洞。然而它已经成为了IETF的标准,因此说接下IE应该尽快地也使用Strict-Transport-Security头部。
固然若是使用了HTTPS,就可没必要使用此头部了,因此说为何不用HTTPS呢?切记HTTPS不只能保证你的内容被加密、不被拦截,还能提供真实性。向用户承诺内容的确来自你。
使用HTTPS还存在着不一样的争论,事实上,博客和这个头部都不是基于HTTPS的,因此争论还会持续好久。
在哪还能学到更多它的知识呢?
Mozilla Developer Network上有一篇不错的文章:HTTP的 Strict Transport Security头部
了解更多 Symfony2能够看Nelmio安全包,而 Drupal 在安全组件模块有详细说明。阅读它们可使你更了解上述介绍的头部。
默认状况下jQuery 发送X-Requested-With头。它认为这个头部能够预防伪造跨站请求。然而这个头部不会产生请求,一个用户会话可由第三方发起,好比在浏览器中XMLHttpRequest就能够自定义头部。
不幸的是,Ruby On Rails 的Ruby框架和Django Python框架的快速建立,虽然这能成为很好的防护手段,但它能够不彻底依赖于像Java或Adobe Flash第三方插件了。
使用以上HTTP头部可帮你快速容易地预防XSS攻击、点击挟持攻击、MIME嗅探和中间人攻击。若是目前还没使用,经过介绍给你,你能够在你的应用或服务器上使用。
请确保用户的安全性。
原文:4 HTTP SECURITY HEADERS YOU SHOULD ALWAYS BE USING
转载自: 伯乐在线 - smilesisi