后记：Cookie安全大辩论总结

前天，我发布在博客园上的某知名电商网站的Cookie漏洞引发园友们的热议，学到了很多知识，现在整理一下其中比较激烈的技术讨论。谁对谁错每个人自己心中都有一把称，很多时候都是我无法说服你，你也无法说服我。

论题1：

网友：https是安全的，在传输过程对cookie等数据进行了有效的加密，所以https站下的Cookie也是安全的；

我：https下的cookie在传输过是安全的，但在客户端上是不安全的，使用客户端的有用户还有黑客；

我的论据：假设在某网站A下，我登录了自己的账号，打开浏览器cookie时发现有一条是这样 user = batsing ，然后我会想我把 user 这个cookie的值改成了别人的用户名是不是直接就可以登录了别人的账号呢？如果服务端程序是直接根据这个cookie值就认为是这个用户的话，那么这样的做法是很可行的。

我的建议：无论有没有使用SSL，Cookie值都一定要经过高强度难破解的加密算法进行处理。

论题2：

网友：哈希算法用在加密领域是可以信赖的

我：哈希算法用在加密领域是不可信赖的

我的论据：1、哈希算法产生的密文具有明显的特征，为黑客破解指明的方向。哈希算法产生的密文全为数字加纯小写字母（或纯大写），MD5为32位，SHA1为40位，SHA-256为64位，SHA-512为128位。2、哈希算法已经有大量的彩虹表和数据库作为破解工具，破解难度大大减少，其安全性值得质疑。

我的建议：所有的密文都要使用没有明显特征，不易被破解的算法进行加密处理，推荐使用AES加密算法（修正：加上与哈希结合）。PS：我以前不知道有AES算法的时候，是混合使用了SHA1、字符串截取和Base64处理的，弄成一眼看上去也不好破解的样子（同时包含数字、大小写还可能有符号←_←）。

总结：

1、Cookie是可以安全使用的；

2、现在几乎每个月都会有几起安全问题被曝光，我们程序员更要提高安全意识；

相关安全议题：

一、注册/登录表单的密码安全

方案1、使用SSL，使表单信息在传输过程中为密文状态，被截获时仍然难以破解利用；

方案2、使用安全控件，比如银行的网页和一些大型电商的网页，在客户端加密了再传输；

方案3、使用JS加密密码，到服务端再解密，但由于JS是可见的，加密算法也是可见的，所以JS文件本身也需要进行加密压缩让其难以阅读；（此非良策）

　　对于JS文件的压缩加密，网上有很多网站提供这样的功能，另外还发现一个有趣的更厉害的“加密”JS的方法，有兴趣的可以点这里>>(备用链接>>);

二、字符串加密

(这里过于笼统又争议较多，所以我现在把它拆分开来)

2-1、数据库密码加密：

方案1、很多网站在用的多重哈希加密；（大多数网友认可，但我个人不推荐）

方案2、哈希加密与AES加密结合；（本来是想单纯AES加密的，园友@xmodygetz评论说单纯AES加密服务器被攻破密钥泄露时会导致密码被破解，所以我在这里作了修正，谢谢这位园友指正）

方案3、现有加密函数加上自己编的一些字符处理方法组合；

2-2、cookie加密(注意cookie和session的区别及用途)

cookie要在服务端生成，不要在前端用js生成，一般都要能在服务端还原出原文，所以加密是可逆的。

方案一、AES；

方案二、自己编的一些函数；

2-3、表单中的密码js加密

我的方案：生成登录页面时后台生成一个随机码密钥给前端表单并用session记录，前端Js加密时使用该随机码作为密钥加密表单，提交密钥和密文给服务端，服务端审核随机码和解密密文。由于密文、密钥和加密方法js都是可截获的，所以此并非良策。

三、Cookie记录用户应包含和验证的原始信息

1、用户ID√ 用于识别用户身份的标识

2、浏览器信息√ 用于阻止部分黑客电脑浏览器直接窃用手机Cookie

3、IP地址ㄨ PC可以用但手机不能用，手机IP经常会变

4、时间戳？用途要看具体算法。如果Cookie密文无法还原出原文的时间戳那么就无法校验时间戳的有效性；如果可以还原，那么此cookie就可以在后台判定在规定时间内有效（注意这里的有效期与平时说的cookie有效期不一样，平时说的有效期是过期会被浏览器清走，而这里的是被窃走的cookie在超过一定时间后就不被后台程序认同）

5、有没有办法获取和使用更独立的信息，最好是与设备绑定的。比如MAC地址，比如手机的序列码。

6、cookie一般网站可以使用，提高用户方便性。但因其有较大被窃取的风险，所以与金钱直接相关的网站/页面建议不使用cookie。

如何让别人把cookie复制走了也无法登录，这个还没有想到比较好的解决方案，求指教。

四、关于Session的安全

1、中间人把sessionid的cookie窃走可以是可以直接登录的；

2、用户在网页内注销登录/安全退出之后（后台处理是PHP的session_destroy() ），那个sessionid也跟着失效了，所以这种情况下那个sessionid的时效很短，留给黑客的利用时间也很少；

3、如果用户不是在网站上退出而是直接关闭浏览器的话，那个sessionid不会失效，黑客利用那个sessionid的cookie还是一直有效的，直到达到服务器设定的session有效期；

4、可以让浏览器在关闭页面时主动向服务器申请关闭session，但是又判断不了这个页面是不是用户打开该网站的唯一一个页面，会造成用户关闭一个标签页就直接退出登录了，除非那个浏览器一次只能打开一个页面，比如微信内置的浏览器；

5、很多手机用户可能有看完但不关闭网页一直挂着的习惯，所以只能等到了服务器设定的session有效期到期才会退出或自动重新登录（用户cookie）而注销sessionid；

6、所以目前来说session的安全只能依赖于传输路径的安全和服务器设定的session有效期；

--2015-11-16续--

五、Cookie的 HttpOnly 和 HTTPS属性

HttpOnly属性是指该Cookie只能通过服务端访问，浏览器JS不能访问，可以有效减少XSS攻击的身份窃取。所以一般情况下，业务Cookie都应该设置为HttpOnly。

HTTPS属性是指该Cookie只有在https情况下才能使用，所以如果你的网站使用了SSL，那么也应该设置这个属性以提高安全性。

相关链接：

1、HTTPS详细介绍

2、MD5/SHA等简单破解网站

3、常用各类哈希加密网站

安全或不安全最终的体现或许只是一行代码，背后的博弈才是“冰山模型”的水下部分