后记：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复制走了也无法登录，这个还没有想到比较好的解决方案，求指教。