攻擊 1：不安全的直接對象引用
假設程序使用基於cookie的身份驗證，並在cookie中提供了userid參數。但是，沒有使用其他會話標識符對此userid進行驗證，因此，攻擊者可以將userid簡單地更改為受害者用戶的標識並獲得對其帳戶的訪問權限
原始請求
GET /userinfo
HOST: harshbothra.tech
Cookies: sessionid=somerandomsessionID;userid=1234;someothercookies=values
...
修改的請求
攻擊者試圖將用戶ID更改為受害者，例如1235
GET /userinfo
HOST: harshbothra.tech
Cookies: sessionid=somerandomsessionID;userid=1235;someothercookies=values
...
攻擊2：提權
在這種情況下，如果使用cookie來定義角色並且沒有進行驗證，則攻擊者可以來執行提權
實際應用過程
1.以受害用戶身份登錄，並使用Burp Suite捕獲請求
2.在Cookies部分中，有一個ROLE參數，該參數的兩位值為00
3.創建一個管理員帳戶，觀察到cookie中的ROLE值現在為11
4.經過進一步檢查“用戶角色和權限”。我觀察到該應用程序使用二進制位定義角色
00：用戶
11：管理員
5.現在，通過將普通用戶帳戶中的ROLE參數更改為11，可以將權限中成功執行特權升級
攻擊 3：文件包含
攻擊者可能利用cookie來執行文件包含攻擊，這聽起來很奇怪，但是取決於應用程序如何實現各種功能，安全問題隨時可能出現
假設應用程序利用以下cookie來顯示歡迎界面
Cookie: banner=welcome.php; someothercookies=value;
該應用程序正在從后端獲取一些welcom.php文件，因此它可能是一個本地文件包含
Cookie: banner=../../../../../../../../etc/passwd; someothercookies=value;
如果在應用程序中的某個位置看到**/etc/passwd**代替了welcome.php，則表示攻擊已成功執行。但是，這種情況很少見
攻擊 4：xss
許多應用程序利用Cookie在應用程序用戶界面中顯示用戶名或某種消息。攻擊者可以篡改此cookie並注入惡意JavaScript，從而導致Self-XSS
原始Cookie Cookie: name=harsh;somecookies=value 修改后的Cookie Cookie: name=<script>alert(document.domain)</script>; somecookies=value
現在，Self-XSS不再具有影響力，並且通常被認為是可以接受的風險
攻擊5：Cookie可猜測
1.通過發布多個cookie並分析它們，檢查cookie是否是隨機生成的
2.檢查是否使用了一些弱密碼或已知密碼。假設cookie使用的是Base64編碼，並且可以輕松地進行解碼/偽造
攻擊 6：敏感數據暴露
有時，cookie用於存儲用戶的個人信息，尤其是在與衛生保健相關的應用程序中。始終檢查以下內容：
只需使用DevTools/Burp Suite/Cookie Editor，檢查Cookie中是否存儲了敏感信息，通常包括：電子郵件，生日，手機，地址，SSN等
攻擊7：未授權訪問
假設應用程序具有以下接口，允許用戶查看一些受保護的敏感信息
GET /protected-resource
HOST: harshbothra.tech
Cookies: sessionid=somesessionID; someotherkey=value
...
現在，攻擊者嘗試直接請求此終結點，而無需通過應用程序的身份驗證
GET /protected-resource
HOST: harshbothra.tech
..
如果應用程序不驗證用戶是否通過身份驗證，則攻擊者可以在不通過應用程序身份驗證的情況下訪問受保護的資源。這將導致直接請求或授權繞過問題
攻擊8：不安全的反序列化
如果cookie使用任何序列化的對象，則可以執行對象注入或基於序列化的攻擊。這使攻擊者可以根據使用序列化對象的方式來執行特權升級，身份驗證繞過和其他攻擊
了解更多：https://portswigger.net/web-security/deserialization/exploiting
攻擊9：參數污染
如果應用程序接受重復參數（多次使用同一參數）或同一參數內的多個值的使用，則可能會受到參數污染或成批分配攻擊的攻擊。
攻擊流程
1.假設cookie使用一個user_id的參數來檢索一些數據。但是將user_id更改為其他值沒啥影響。
2.攻擊者嘗試使用受害者的用戶ID將額外的user_id參數值添加到cookie。就像：user_id = attacker＆user_id = victim
3.結果，由於應用程序的參數處理首選項被賦予后一個參數，並且繞過了檢查，因此攻擊者能夠檢索“victim”的數據。
攻擊10：缺少Cookie安全屬性
這是一個簡單的安全性錯誤配置，很容易檢查。登錄到應用程序后，請使用任何cookie編輯器或Browser Developer Tools來查看cookie是否缺少以下屬性（未設置標志）：
**HTTPOnly：**使用Cookie攻擊（例如XSS）防止cookie被盜。
Secure：防止cookie被不安全的通信渠道和中間人攻擊等攻擊所竊取
如何預防
1.開啟必需的cookie安全屬性，例如HTTPOnly和Secure。
2.確保不使用純cookie來定義特權。例如，不應執行發送角色參數以定義特權的操作。
3.確保沒有敏感數據直接在Cookie中使用。如果由於任何業務需求而需要使用此數據，請確保對其進行了高度加密並且不能將其解密。
4.對接口上進行驗證，杜絕未授權訪問。
5.與基於cookie的身份驗證相比，首選基於令牌的身份驗證，或實施其他Authorization標頭，以確保更大程度地減少此類攻擊嘗試。
6.切勿允許使用Cookie讀取服務器端組件（例如文件），並確保進行適當的驗證檢查以減輕此類攻擊。