推荐 OWASP - Transport Layer Protection Cheat Sheet

昨天出来的一份传输层保护的Cheat Sheet

实际上主要是 TLS 的正确部署指导原则，我仔细阅读了一遍，非常不错。(注：TLS 1.0 和 SSL 3.0 差别很小)

Transport Layer Protection Cheat Sheet

最近几年来， SSL方面的问题出的非常多，前不久的blackhat大会上就有两场非常精彩的talk。这方面的问题也越来越引起人们的关注，可以预见到的是，在未来很长一段时间内，SSL漏洞会持续更新。

而我们今天的web应用中，很多即便部署了SSL，但可能由于部署人员对SSL、TLS认识上的不足，导致了很多缺陷，从而引起黑客攻击的可能。所以这份Cheat Sheet 的意义弥足珍贵，从指导性的意义上来说，可以算是填补了一项空白。

国内在SSL攻防方面的研究还处于起步阶段，我现在能够找到的文档大部分都是国外的，国内的具有创新性的研究文档（无论攻防），还没有看到。

这次OWASP的 Cheat Sheet 写的算比较全面，但是具体细节方面还是比较欠缺，很多规则所对抗的威胁只是描述性的文字一笔带过，要知道这里提到的很多东西，我都看到过长篇大论的paper。所以这种概括性的东西，对于网站的安全人员来说，比较难以理解具体威胁，也难以以此为凭据去说服开发人员改变安全策略。

所以为了方便大家使用，我简单注释一下这篇Cheat Sheet 的几个rule。

Secure Server Design

Rule - Use TLS for All Login Pages and All Authenticated Pages

用TLS保护所有登录和认证页面，这个应该很好理解。但是rule中讲到login的landing page也要保护起来。这点是目前很多网站都没有做到的。

就是 http://login.xxx.com/login.html  这个页面，里面包含了一个表单，提交到 https://login.xxx.com/authCheck 去验证用户名和密码。这个 http://login.xxx.com/login.html 也需要改成 https://login.xxx.com/login.html ，为的是对抗攻击者从这个login的 landing page 发起攻击(包括篡改等)，从而窃取密码。

Rule - Use TLS on Any Networks (External and Internal) Transmitting Sensitive Data

敏感信息传输使用TLS加密保护。
文中提到内网也一样要做，很多安全事件是从内部发生的。

Rule - Do Not Provide Non-TLS Pages for Secure Content

安全内容不要提供非安全的页面
比如 https://www.xxx.com/userdata  这是一个敏感页面，这个页面就应该配置为只允许 https访问，如果允许 http://www.xxx.com/userdata，那么就可能被攻击者利用非https页面获取访问的内容。

目前的W3C新标准可以通过新增加一个HTTP头的形式强制客户端浏览器使用https浏览某个域下的所有页面，能够起到更好的保护。不过推广这一标准尚需要时间（浏览器支持与更新、普及的时间成本）

可以参考: ForceHTTPS 的标准

Rule - Do Not Perform Redirects from Non-TLS Page to TLS Login Page

重定向这个可能引起中间人攻击，但是文中也没给出太好的解决方案。而对于现在的网站来说，出于可用性的考虑，一些主要页面在未来很长一段时间内还是需要使用这种重定向的方式.

参考：又一个猥琐的技巧：Surf Jacking

Rule - Do Not Mix TLS and Non-TLS Content

页面中混合了非https的内容的话，可能会引起DOM注入从而使得https的页面受到威胁
这种攻击可以叫 mixed content 攻击

Rule - Use "Secure" Cookie Flag

cookie 的 secure flag可以保证该cookie只在https下发送。如果https的站点cookie没有加这个标志，则可能在http的情况下泄露这个cookie。

注意攻击者只需要攻击上行流量就可以了，即便站点不提供该域的http访问，浏览器也会把这个cookie发送出来，从而可能被sniffer到。

Rule - Keep Sensitive Data Out of the URL

敏感信息不要放在url中
主要是一些referer中包含的信息可能会泄露敏感信息。
我之前另外一篇blog讲过这个问题：anti-CSRF Token布署时需要注意的一点问题
值得注意的是，从 https 跳往http，referer是不会发送的，浏览器出于安全原因屏蔽了referer的发送。
但是 https 跳往 https仍然会发送referer

Server Certificate & Protocol Configuration

Rule - Use an Appropriate Certificate Authority for the Application's User Base

使用一个商业证书（需要从CA签发机构购买，比如VeriSign），如果是自己生成的浏览器会弹窗说不认识，虽然证书也能用，但是证书两大功能之一的认证功能就不能用了。从而使得钓鱼和中间人攻击有机可乘。

Rule - Only Support Strong Cryptographic Ciphers

现在很多网站用的证书还支持弱加密算法
检测的方法可以参考我之前写的： SSL 的那点事
今年曾经爆出的用200台PS3破解MD5也是针对SSL的攻击，有兴趣的可以google一下

Rule - Only Support Strong Protocols

SSL 2.0 已经多次被证明存在缺陷，所以任何情况下都不应该再支持。
推荐使用TLS，但是对浏览器版本有一定的要求。

Rule - Use Strong Keys & Protect Them

文中推荐使用2048bit的key

Rule - Use a Certificate That Supports All Available Domain Names

证书要支持所有的域和子域，因为现在很多CA机构签发证书资质考核不严谨，只要有这个域的邮箱就能够签发这个域的证书了，直接引起了攻击者能够从CA处获得一张合法的证书。而使用0字节等技巧更是可以欺骗浏览器。

参考：BlackHat 的议题听后感

目前这些问题也渐渐被解决了。同时推荐使用 EV 证书，会起到更好的效果( 当然也更贵 )。




最后还是推荐仔细阅读这份文档，并按照其指导性原则来实施，避免好心办坏事，酿成悲剧。