在本文中，我们将研究Cookie的各种攻击情形。下图是有关基于Cookie的身份验证漏洞的详细思维导图。

攻击场景

现在，我们将从上方的思维导图中了解一些有趣的攻击情形。为您提供工具，让您在偶然发现Cookie时能更好地了解自己的攻击面。

攻击 1：不安全的直接对象引用

假设程序使用基于cookie的身份验证，并在cookie中提供了userid参数。但是，没有使用其他会话标识符对此userid进行验证，因此，攻击者可以将userid简单地更改为受害者用户的标识并获得对其帐户的访问权限。

原始请求

**修改的请求

攻击者试图将用户ID更改为受害者，例如1235。**

攻击2：提权

在这种情况下，如果使用cookie来定义角色）并且没有进行验证，则攻击者可以来执行提权。

实际应用过程

攻击 3：文件包含

攻击者可能利用cookie来执行文件包含攻击，这听起来很奇怪，但是取决于应用程序如何实现各种功能，安全问题随时可能出现。

假设应用程序利用以下cookie来显示欢迎界面。

该应用程序正在从后端获取一些welcom.php文件，因此它可能是一个本地文件包含。

如果在应用程序中的某个位置看到**/etc/passwd**代替了welcome.php，则表示攻击已成功执行。但是，这种情况很少见

攻击 4：xss

许多应用程序利用Cookie在应用程序用户界面中显示用户名或某种消息。攻击者可以篡改此cookie并注入恶意JavaScript，从而导致Self-XSS。

现在，Self-XSS不再具有影响力，并且通常被认为是可以接受的风险。

攻击5：Cookie可猜测

1.通过发布多个cookie并分析它们，检查cookie是否是随机生成的。

2.检查是否使用了一些弱密码或已知密码。假设cookie使用的是Base64编码，并且可以轻松地进行解码/伪造。

攻击 6：敏感数据暴露

有时，cookie用于存储用户的个人信息，尤其是在与卫生保健相关的应用程序中。始终检查以下内容：

攻击7：未授权访问

假设应用程序具有以下接口，允许用户查看一些受保护的敏感信息。

现在，攻击者尝试直接请求此终结点，而无需通过应用程序的身份验证。

如果应用程序不验证用户是否通过身份验证，则攻击者可以在不通过应用程序身份验证的情况下访问受保护的资源。这将导致直接请求或授权绕过问题。

攻击8：不安全的反序列化

如果cookie使用任何序列化的对象，则可以执行对象注入或基于序列化的攻击。这使攻击者可以根据使用序列化对象的方式来执行特权升级，身份验证绕过和其他攻击。

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

攻击9：参数污染

如果应用程序接受重复参数（多次使用同一参数）或同一参数内的多个值的使用，则可能会受到参数污染或成批分配攻击的攻击。

攻击流程

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

原文地址?