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文件本身也需要进行加密压缩让其难以阅读；

二、字符串加密

方案1、很多网站在用的多重哈希加密；（不推荐）

方案2、AES加密；

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

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

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

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

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

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

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

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

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

新闻名称：Cookie安全大辩论总结
当前地址：http://www.shufengxianlan.com/qtweb/news29/476029.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联