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令牌，而此值在受害者登录后将保持不变），攻击者可以设置这个已知值，然后滥用它（在这种情况下，攻击者可以让用户执行CSRF请求，因为他知道CSRF令牌）。
就像设置值一样，攻击者还可以获取服务器生成的未经身份验证的cookie，从中获取CSRF令牌并使用它。
Cookie顺序
当浏览器接收到两个具有相同名称的cookie 部分影响相同范围（域、子域和路径）时，浏览器将在请求时发送两个cookie的值，只要两者对请求都有效。
取决于谁具有最具体路径或哪个是最旧的，浏览器将首先设置cookie的值，然后设置另一个值，如：Cookie: iduser=MoreSpecificAndOldestCookie; iduser=LessSpecific;
大多数网站将仅使用第一个值。因此，如果攻击者想要设置一个cookie，最好在另一个cookie设置之前设置它，或者使用更具体的路径设置它。
此外，在更具体的路径中设置cookie的能力非常有趣，因为您将能够使受害者使用他的cookie，除了在恶意cookie设置将在之前发送的特定路径中之外。
防护绕过
对抗这种攻击的可能保护措施是，Web服务器不会接受具有相同名称但两个不同值的两个cookie的请求。
为了绕过攻击者在受害者已经获得cookie后设置cookie的情况，攻击者可以引起cookie溢出，然后，一旦合法cookie被删除，设置恶意cookie。
pageCookie Jar Overflow另一个有用的绕过方法可能是对cookie名称进行URL编码，因为一些保护措施会检查请求中具有相同名称的2个cookie，然后服务器将解码cookie的名称。
Cookie炸弹
Cookie Tossing攻击也可以用于执行Cookie炸弹攻击：
pageCookie Bomb防御措施
在cookie名称中使用前缀__Host
__Host如果cookie名称具有此前缀，只有在标记为安全，从安全来源发送，不包括Domain属性，并且Path属性设置为/的情况下，它才会被接受在Set-Cookie指令中
这可以防止子域强制将cookie发送到顶级域，因为这些cookie可以被视为“锁定域”
参考资料
最后更新于