Cookie Tossing
描述
如果攻击者能够控制一个子域名或公司的域名，或者在子域名中发现 XSS，他将能够执行此攻击。
正如在 Cookies Hacking 部分所指出的，当cookie 被设置到一个域（指定它）时，它将在该域及其子域中使用。
因此，攻击者将能够将特定 cookie 设置到域和子域，执行类似 document.cookie="session=1234; Path=/app/login; domain=.example.com"
这可能是危险的，因为攻击者可能能够：
将受害者的 cookie 固定到攻击者的账户，因此如果用户没有注意，他将在攻击者的账户中执行操作，攻击者可能获得一些有趣的信息（查看用户在平台上的搜索历史，受害者可能在账户中设置他的信用卡...）
如果cookie 在登录后没有改变，攻击者可能只需固定一个 cookie（会话固定），等待受害者登录，然后使用该 cookie 以受害者身份登录。
有时，即使会话 cookie 发生变化，攻击者也会使用之前的 cookie，并且他也会收到新的 cookie。
如果cookie 设置了一些初始值（例如在 flask 中，cookie 可能设置会话的 CSRF token，并且该值将在受害者登录后保持），攻击者可能设置这个已知值，然后滥用它（在这种情况下，攻击者可能会让用户执行 CSRF 请求，因为他知道 CSRF token）。
就像设置值一样，攻击者还可以获取服务器生成的未认证 cookie，从中获取 CSRF token 并使用它。
Cookie 顺序
当浏览器接收到两个具有相同名称的 cookie 部分影响相同范围（域、子域和路径）时，浏览器将在请求有效时发送这两个 cookie 的值。
根据谁具有最具体的路径或哪个是最旧的，浏览器将首先设置 cookie 的值，然后设置另一个的值，如：Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;
大多数网站将只使用第一个值。因此，如果攻击者想要设置一个 cookie，最好在设置另一个之前设置它，或者设置一个更具体的路径。
此外，在更具体的路径中设置 cookie 的能力非常有趣，因为您将能够让受害者在他的 cookie 中工作，除了恶意 cookie 设置将被发送之前的特定路径。
保护绕过
对这种攻击的可能保护是Web 服务器不接受具有相同名称但两个不同值的两个 cookie 的请求。
为了绕过攻击者在受害者已经获得 cookie 后设置 cookie 的场景，攻击者可以造成cookie 溢出，然后，一旦合法 cookie 被删除，设置恶意 cookie。
Cookie Jar Overflow另一个有用的绕过可能是对 cookie 名称进行 URL 编码，因为一些保护措施检查请求中是否有两个具有相同名称的 cookie，然后服务器将解码 cookie 的名称。
Cookie 炸弹
Cookie Tossing 攻击也可以用于执行Cookie 炸弹攻击：
Cookie Bomb防御
在 cookie 名称中使用前缀 __Host
__Host如果 cookie 名称具有此前缀，只有在标记为安全、从安全来源发送、不包括域属性并且路径属性设置为 / 时，才会在 Set-Cookie 指令中被接受
这防止子域强制 cookie 到顶级域，因为这些 cookie 可以被视为“域锁定”
参考
Last updated
