我在做用戶登陸時大費周章，又是rsa又是md5的，忽然想起DNS欺騙的問題，如果用戶被dns劫持，不管我用什么樣的方法，用戶如果在被劫持的頁面上輸入密碼都毫無安全可言，并且https我們是不可能用的，瞎將就吧，我只能寄希望于用戶裝了某管家或某衛士。 但是后面的問題更嚴重，大家都知道http依賴cookie保持會話狀態，我們大費周章地用各種加密方式來保護用戶密碼，最后卻轉化成為十幾二十個明文字符來標識用戶身份。找個抓包工具來截獲這串數據并不是難事，而想偽造cookie就更簡單了，這就是說，如果你登陸成功，其它人就很可能和你"共享"這個帳號了，所以只依靠sessionID就完全信任用戶發來的請求十分危險。 有如下解決方案： 步驟一：用戶打開登陸頁面，獲得RSA公鑰 步驟二：用戶點擊登陸時在瀏覽器生成一個隨機串我們稱之為key，將key保存在用戶瀏覽器中（需要html5支持），此key將會是身份認證的關鍵 步驟三：瀏覽器將password和key分別使用RSA公鑰加密并發送至服務器 步驟四：服務器解密password和key并將key緩存入session 步驟五：服務器返回一個隨機串，存入cookie和session中（我們將此隨機串稱為nonceStr，其只可以作為下一次校驗的簽名參數之一） 至此為止只有發送key的瀏覽器和擁有RSA私鑰的服務器知道key的具體內容，我們可以使用任意一種簽名方式來驗證請求的來源，這里給出一種類似微信的簽名方式： 客戶端收到nonceStr后 步驟六：將瀏覽器中的key和cookie中的nonceStr拼接成key=keyVal&nonceStr=nonceStrVal 步驟七：使用md5進行摘要，并使用hex進行編碼得到sign，使用js將sign添加到cookie中 用戶發送請求至服務器后，需要配置攔截器攔截所有需要校驗的鏈接 步驟八：服務器端從session中取出key并從session中取出nonceStr（cookie中的nonceStr用戶可偽造從而造成一個nonceStr和sign的組合頂替了原先sessionID的位置，所以服務端認證時不能從cookie中獲取）重復上面第二到四步的簽名過程 步驟九：將計算得出的sign與cookie中的sign對比完成校驗 步驟十：如果校驗成功服務器更新session中的nonceStr并將其放入cookie和session中準備好下一次校驗 以上的方法還存在問題，如果你第一次發送的請求因為某些原因被攔截或沒有成功，并且有人此時監聽到你發送的cookie中的sign他便可以偽造一次請求，但此方法的好處是寫一個js腳本引入即可一定程度上保證安全對頁面幾乎沒有影響 如果安全要求比較高那么就只能對所有要提交的數據進行簽名，但對前臺代碼的影響太大，而且對每個鏈接的所有參數簽名并替換所有鏈接（有的ajax和圖片src也需要簽名）也不太現實。只能針對某些特定的鏈接使用