Cookie Tossing

Reading time: 6 minutes

描述

如果攻击者能够控制一个子域或公司的域名，或者在子域中发现XSS，他将能够执行此攻击。

正如在Cookies Hacking部分所指出的，当cookie被设置到一个域（指定它）时，它将在该域及子域中使用。

这可能是危险的，因为攻击者可能能够：

• 将受害者的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被设置之前设置它，或者设置一个更具体的路径。

保护绕过

对这种攻击的可能保护措施是web服务器不接受具有相同名称但两个不同值的两个cookie的请求。

为了绕过攻击者在受害者已经获得cookie后设置cookie的场景，攻击者可以造成cookie溢出，然后，一旦合法cookie被删除，设置恶意cookie。

Cookie Jar Overflow

另一个有用的绕过可能是URL编码cookie的名称，因为一些保护措施检查请求中是否有两个具有相同名称的cookie，然后服务器将解码cookie的名称。

Cookie炸弹

Cookie Tossing攻击也可以用于执行Cookie炸弹攻击：

Cookie Bomb

防御

在cookie名称中使用前缀__Host

• 如果cookie名称具有此前缀，**只有在标记为安全、从安全来源发送、不包括域属性并且路径属性设置为/**时，它将被接受在Set-Cookie指令中。
• 这防止子域强制cookie到顶级域，因为这些cookie可以被视为“域锁定”。

参考

• @blueminimal
• https://speakerdeck.com/filedescriptor/the-cookie-monster-in-your-browsers
• https://github.blog/2013-04-09-yummy-cookies-across-domains/
• Cookie Crumbles: Unveiling Web Session Integrity Vulnerabilities