前天，我發布在博客園上的某知名電商網站的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安全大辩论总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。