后记：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、常用各類哈希加密網站
安全或不安全最終的體現或許只是一行代碼，背后的博弈才是“冰山模型”的水下部分
轉載于:https://www.cnblogs.com/batsing/p/4878832.html
總結
以上是生活随笔為你收集整理的后记：Cookie安全大辩论总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 马自达将于2027年推出电动汽车专用平台
- 下一篇： ios device provision