后记：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，那么也应该设置这个属性以提高安全性。
相关链接：
安全或不安全最终的体现或许只是一行代码，背后的博弈才是“冰山模型”的水下部分
