公司專案重構 Web安全 認證和會話管理

3、防範手段

二、在會話管理方面

如時間有限，可直接閱讀防範手段一節。

今年開始公司準備對專案做部分重構，其中安全性問題首當其衝，除了已知的問題外，還需要發散思維，盡可能找出更多的潛在問題。期間發現一本非常好的書《白帽子講web安全》，感謝吳翰清大佬，讀完本書讓我對web安全有了更深刻的理解，強烈推薦大家閱讀。

我打算記錄下整個安全性重構的過程，相關知識點大部分會摘抄自《白帽子講web安全》，因為總結的很到位了，最後記錄下公司內採用的防範手段（敏感資訊不會書寫）。

首先需要知道」認證(authentication)「和」授權(authorization)「的區別:

-> 認證的目的是為了認出使用者是誰，授權的目的為了決定使用者能做什麼

-> 認證實際上就是乙個驗證憑證的過程，常用憑證如賬號密碼、指紋等

賬號密碼憑證還是目前比較普遍的做法，實現成本低、認證簡單，缺點是安全性比較弱，容易被猜測，因為使用者可能會輸入易猜測的簡單密碼，因此需要有一套完善的密碼方案。

這裡只談密碼認證的攻擊方式。除了暴力破解外，黑客常用的手段就是猜測，維護乙份弱密碼列表，比如123456，或嘗試輸入使用者相關資訊作為密碼輸入，比如出生日期、姓名拼音等。這種攻擊成本很低，而且效果往往會更好。

又或者採用撞庫的方式，因為很多網友都習慣使用同一密碼。

session劫持

sessionid一旦在生命週期內被竊取，就等同於賬戶失竊，因為攻擊者已不需要攻擊登入過程，這種攻擊方式稱為session劫持，如果sessionid儲存在cookie中則又稱為cookie劫持。其方式有很多，比如xss攻擊、網路sniff、本地木馬讀取。xss漏洞可以通過將會話cookie設定為httponly(js不可讀)，網路sniff和木馬只能在客戶端著手解決了。

sessionid暴露

書裡提到了曾經qq的wap郵箱的漏洞，他們是將會話id儲存在url中，沒儲存在cookie中(可能以前很多手機不支援cookie吧)，那麼如果故意在傳送的郵箱內容中引用一張外部**，借助referer的機制，在外部**的伺服器訪問日誌中可以拿到referer資訊，這樣sid就暴露了。

注意：有時候會不經意間犯類似這種錯誤，比如前後端分離後，如果前端將會話token跟在url引數後（比如有頁面之間的跳轉，需要傳遞token），就可能會被攻擊者利用。一定要慎重，sid的方式我們肯定是廢棄的，但也要引起注意是否可能發生同類風險。

session fixation攻擊 和 session保持攻擊

意思是：如果登入前後的使用者sessionid沒有變化，則有可能存在session fixation問題。

比如攻擊者設法將帶有sessionid的位址（比如剛才講的sid問題）傳送給使用者，並誘導使用者開啟登入，由於伺服器未更新sessionid的值，導致攻擊者也可以訪問使用者賬戶了。

會話保持：攻擊者持有使用者se

從使用者輸入密碼，到程式儲存密碼、再到認證密碼的過程中，都要嚴格遵守以下規範：

在註冊時，增加密碼強度檢測功能，並以友好的方式告知使用者輸入密碼的強度：

一般專案都有自己的密碼強度校驗規則，owasp推薦了一些策略方案：

密碼長度上：

密碼複雜度上：

除了owasp推薦的策略外，還要注意不能使用使用者公開資料作為密碼或密碼的部分組成，比如姓名拼音、手機號、生日等，這些資訊往往都是公開的，很容易被猜測。

推薦公司根據業務場景制定自己的密碼強度規範，並維護乙份弱密碼列表，只要是不合法要求的密碼，都提示使用者此密碼不安全或強制讓其修改。

在密碼入庫的時候一定不要直接儲存明文密碼，必須採用不可逆的加密演算法（常見的加密演算法有md5或sha-1），將加密後的密碼儲存到資料庫中。這樣內部人員也看不到使用者密碼，而且就算被黑客攻擊也看不到。

在使用者登入認證的時候，僅對使用者輸入的密碼進行同樣規則加密，再與庫內儲存的「密碼」進行匹配是否一致即可。

防止命中彩虹表：

彩虹表：收集足夠多的密碼明文與密文的對應表，比如**：www.cmd5.com

在不可逆加密演算法的基礎上，還要為使用者設定的密碼新增額外隨機字串（稱為salt）來增強複雜度，md5(password+salt)，這樣可以使彩虹表攻擊方式失效。salt可以儲存到伺服器配置檔案中或使用者資訊表中這樣每個使用者都隨機生成不同的。

在重要的場景下，比如支付扣款、修改重要資料時，可讓其輸入支付密碼（非登入密碼）或簡訊驗證碼來驗證是否本人操作。

多因素認證能夠提高攻擊的門檻，攻擊者必須通過所有的認證機制，比如能夠成功支付的前提是，必須知道使用者的登入密碼和支付密碼。

比如密碼輸入錯誤超過一定次數就凍結賬號一段時間。當然了這個功能有可能會被惡意利用凍結別人賬號。建議還是新增行為驗證碼，常見的有拖拽、點選、拼圖等花樣，在使用者輸入錯誤密碼超過幾次後強制進行驗證碼驗證，這樣也不會影響正常使用者的體驗。

還有其他方式，但可能會影響使用者的體驗。

設定為httponly的cookie，js讀取不到，可以防止由xxs引起的cookie劫持。

在使用者登入時，將ip、user-agent或其他標識資訊也儲存起來，每次請求校驗這些資訊與之前儲存的是否一致，如果發生改變強制下線。

還有其他方式：

單點登入

如果公司是多個團隊協作開發，建議開發單點登入系統，將使用者安全保障集中起來由專門團隊維護。

暫時就寫到這裡，如有變化，會及時更新的。如有錯誤，請大家及時提出。

再次感謝吳翰清大佬！

公司專案重構 Web安全 訪問控制

如時間有限，可直接閱讀防範手段一節。今年開始公司準備對專案做部分重構，其中安全性問題首當其衝，除了已知的問題外，還需要發散思維，盡可能找出更多的潛在問題。期間發現一本非常好的書 白帽子講web安全 感謝吳翰清大佬，讀完本書讓我對web安全有了更深刻的理解，強烈推薦大家閱讀。我打算記錄下整個安全性重構...

WEB安全之web應用認證基本概念

一 http常見認證機制 1 基本認證 1 客戶端訪問乙個受http基本認證保護的資源 2 服務端返回乙個狀態碼401or403 沒有授權or沒有許可權登入，要求客戶端提供使用者名稱和密碼 3 客戶端將輸入的使用者名稱和密碼進行base64編碼後，採用非加密的明文形式給服務單，如 authoriza...

安全漏洞問題7 失效的身份認證和會話管理

安全漏洞問題7 失效的身份認證和會話管理 1.1.漏洞描述 應用程式的功能一般包含許可權管理和會話管理，但是由於應用程式設計不當，讓攻擊者可以竊取到密碼 金鑰 session tokens等資訊，進而冒充合法使用者身份，獲取敏感資訊或者進行惡意操作。1.2.漏洞危害 利用不安全的許可權管理和會話管理...