背景：
在網際網路**中，使用者註冊，登入幾乎是每個**的標配功能。在一般人看來乙個小小的登入業務表面上看起來很簡單 ，大概過程是這樣的：使用者在前台頁面輸入使用者名稱和密碼，然後後台web伺服器拿到使用者輸入資訊，在資料庫裡根據使用者名稱和密碼匹配一下，有資料返回，表示使用者的賬號和密碼匹配成功，跳轉到相關頁面；沒有則返回登入錯誤提示使用者。這個小小的業務流程看似很簡單，但是因為涉及到使用者賬號和密碼這類關鍵性使用者資料，常常成為黑客的攻擊點。比如：csdn被人拖庫，密碼報出明文儲存，小公尺**爆出洩漏使用者登入資訊（小公尺技術人比較牛，密碼洩漏後，做了兩件事情，第一承認使用者賬號洩漏，第二洩漏後叫使用者別怕，因為加密儲存了密碼，黑客拿到的是加密後的密碼）。京東，支付寶等大的網際網路**等也有暴露過相關洩漏使用者賬號黑客事件。
由於程式設計師的開發技術水平參差不齊，專案進度，或者壓根就沒安全意識等因素，導致編寫的使用者註冊，登入功能存在很大的安全風險。安全小菜鳥在這裡羅列一二，以備不時之需。
遇到的安全問題：
1、 拖庫
由於程式中存在sql注入漏洞，在客戶端輸入資訊時，使用者惡意輸入一些sql語句，導致資料庫裡的使用者資訊被黑客竊取（有興趣的同學可以上網搜搜怎樣進行sql注入攻擊，進行拖庫），然後使用者的賬號資訊就被黑客拿到，然後黑客就可以幹很多事情了。
應對措施：
對存入資料庫中的密碼，進行加密儲存。有些技術人員為了省事，直接用「原始密碼」md5加密後儲存。 md5雖然不能解密，但是原始值md5加密後的值是不變，根據這些特性可以通過碰撞檢測，字典表等猜出使用者的密碼。即根據字串的組合，md5加密後，生成加密值，存入md5庫；然後根據洩漏**的密碼從md5庫里一查，什麼都有了。現在都有**提供「md5解密」功能，原理猜測估計是根據碰撞檢測。
原始密碼用md5加密不能用那用什麼了？
加鹽儲存：使用者的密碼+鹽（固定格式的隨機字串）然後在用md5加密或者相應的hash函式進行加密；加密後的字串和固定格式的隨機字串需要儲存關聯存入庫里；下次使用者登入時，使用密碼+鹽，再呼叫相應的加密演算法，算出加密後的值和庫里的密碼值是否相同，如果相同則登入成功，否則登入失敗。
鹽：可以使用註冊時間+使用者名稱等，有網上專家建議使用「基於加密的偽隨機數生成器」來生成鹽，見
好處
1、增加原始加密字串的長度，黑客在碰撞長字串時花費更多的時間（理論上來說還是可以破解不過破解所花費的和獲得利益就需要黑客評估了）
2、增加了破解難度，如果鹽值不隨機，而採用固定鹽值，或者短鹽值，黑客也可以通過「猜測的密碼」+短鹽值，加密後，快速對比洩漏的密碼，而獲得原始密碼。
除了從技術上解決完，還要加強線上安全掃瞄或者安全**審查。
2、 客戶端無限制登入
有些登入介面，在登入多少失敗時，沒有任何限制，這樣就造成了黑客可以無限制呼叫登入介面，達到暴力破解的目的。
應對措施：加驗證碼。驗證碼也有可能被高明的黑客破解。
如果不行；加使用者名稱登入錯誤次數檢驗；或者ip登入次數限制。
3、 cookie被盜，xss攻擊
大多數網際網路應用，都用cookie來標示使用者登入資訊，如果cookie被黑客盜用，也就等於使用者登入的令牌已經被黑客竊取，然後使用者在自己的瀏覽器裡種入cookie，冒充使用者已經登入。盜取cookie一般是用xss攻擊，即在頁面上提交資訊的字段
裡加入一段惡意的js指令碼，其它使用者在瀏覽資訊時，執行這段惡意的腳步，然後把瀏覽資訊使用者的cookie發到黑客伺服器裡，然後黑客就可以冒充被黑使用者了。
應對措施：
對於使用者可控輸入的資訊，進行展現，都做html編碼。
設定httponly屬性，防止客戶端指令碼訪問cookie
4、 httponly突破，中間人攻擊
設定httponly，或者做xss腳步處理，cookie資訊就安全了嗎？
no，客戶端和服務端的http通訊，在整個網路傳輸時，是明天傳輸，中間人可以控制路由器等網路裝置，抓取這些網路裝置上的資料，由於明文傳輸，一分析，什麼都出來。
應對措施：設定secure屬性，cookie只能在https 下發送到服務端，所有的http通訊都加密，即使中間人擷取到網路通訊資料，也無法解密出資料。
分享到：
一種多租戶系統架構 |
jvm之classloader 初探
參考知識庫
語音識別與合成知識庫
110 關注 |
141 收錄
計算機視覺知識庫
197 關注 |
187 收錄
自然語言理解和處理知識庫
125 關注 |
55 收錄
android知識庫
32586 關注 |
2675 收錄
liuwenjie517333
最近訪客 更多訪客》
-苦行僧-
eagle2008
victorxia
無賴木乃伊
文章分類
社群版塊
存檔分類
登入安全問題策略
使用者登入介面 img 客戶感覺每次都要輸入驗證碼不爽，那麼你會怎麼做？三次輸入錯誤，24小時內都要驗證碼 我知道的三種解決方法 cookie session 資料庫表記錄 三種儲存方式，資料庫最安全，還可以判斷下對方的ip，根據對方ip儲存，可是我們專案是門戶型 這個使用者量是很大的。cookie...
前端登入安全問題
對於前端開發來說安全問題很重要，我們不希望自己的密碼之類的資訊暴露出來被人獲取。如果前端不加以限制，很多重要資訊容易洩露。比如我們登入的時候，提交post，我們在瀏覽器控制台network的http請求中會直接看到密碼。http協議是明文傳輸，只要別人一抓包就可以獲取到傳輸的報文。那為了讓資料傳輸更...
使用者登入驗證安全問題
關於登入驗證安全問題，使用者名稱和密碼使用 1 1 or 1 1 典型的sql sql select from 表where user user and pass pass 為避免 sql select from 表where user 1 1 or 1 1 and pass 1 1 or 1 1 ...