实战中常见的十种cookie漏洞
攻击 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读取服务器端组件（例如文件），并确保进行适当的验证检查以减轻此类攻击。
