實戰中常見的十種cookie漏洞

假設程式使用基于cookie的身份驗證，并在cookie中提供了userid參數。但是，沒有使用其他會話辨別符對此userid進行驗證，是以，攻擊者可以将userid簡單地更改為受害者使用者的辨別并獲得對其帳戶的通路權限

原始請求

修改的請求

攻擊者試圖将使用者ID更改為受害者，例如1235

在這種情況下，如果使用cookie來定義角色并且沒有進行驗證，則攻擊者可以來執行提權

實際應用過程

1.以受害使用者身份登入，并使用Burp Suite捕獲請求

2.在Cookies部分中，有一個ROLE參數，該參數的兩位值為00

3.建立一個管理者帳戶，觀察到cookie中的ROLE值現在為11

4.經過進一步檢查“使用者角色和權限”。我觀察到該應用程式使用二進制位定義角色

00：使用者

11：管理者

5.現在，通過将普通使用者帳戶中的ROLE參數更改為11，可以将權限中成功執行特權更新

攻擊者可能利用cookie來執行檔案包含攻擊，這聽起來很奇怪，但是取決于應用程式如何實作各種功能，安全問題随時可能出現

假設應用程式利用以下cookie來顯示歡迎界面

該應用程式正在從後端擷取一些welcom.php檔案，是以它可能是一個本地檔案包含

如果在應用程式中的某個位置看到**/etc/passwd**代替了welcome.php，則表示攻擊已成功執行。但是，這種情況很少見

許多應用程式利用Cookie在應用程式使用者界面中顯示使用者名或某種消息。攻擊者可以篡改此cookie并注入惡意JavaScript，進而導緻Self-XSS

現在，Self-XSS不再具有影響力，并且通常被認為是可以接受的風險

1.通過釋出多個cookie并分析它們，檢查cookie是否是随機生成的

2.檢查是否使用了一些弱密碼或已知密碼。假設cookie使用的是Base64編碼，并且可以輕松地進行解碼/僞造

有時，cookie用于存儲使用者的個人資訊，尤其是在與衛生保健相關的應用程式中。始終檢查以下内容：

假設應用程式具有以下接口，允許使用者檢視一些受保護的敏感資訊

現在，攻擊者嘗試直接請求此終結點，而無需通過應用程式的身份驗證

如果應用程式不驗證使用者是否通過身份驗證，則攻擊者可以在不通過應用程式身份驗證的情況下通路受保護的資源。這将導緻直接請求或授權繞過問題

如果cookie使用任何序列化的對象，則可以執行對象注入或基于序列化的攻擊。這使攻擊者可以根據使用序列化對象的方式來執行特權更新，身份驗證繞過和其他攻擊

了解更多：https://portswigger.net/web-security/deserialization/exploiting

如果應用程式接受重複參數（多次使用同一參數）或同一參數内的多個值的使用，則可能會受到參數污染或成批配置設定攻擊的攻擊。

攻擊流程

這是一個簡單的安全性錯誤配置，很容易檢查。登入到應用程式後，請使用任何cookie編輯器或Browser Developer Tools來檢視cookie是否缺少以下屬性（未設定标志）：

1.開啟必需的cookie安全屬性，例如HTTPOnly和Secure。

2.確定不使用純cookie來定義特權。例如，不應執行發送角色參數以定義特權的操作。

3.確定沒有敏感資料直接在Cookie中使用。如果由于任何業務需求而需要使用此資料，請確定對其進行了高度加密并且不能将其解密。

4.對接口上進行驗證，杜絕未授權通路。

5.與基于cookie的身份驗證相比，首選基于令牌的身份驗證，或實施其他Authorization标頭，以確定更大程度地減少此類攻擊嘗試。

6.切勿允許使用Cookie讀取伺服器端元件（例如檔案），并確定進行适當的驗證檢查以減輕此類攻擊。