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。
Cookie Jar Overflow另一个有用的绕过方法可能是对cookie名称进行URL编码,因为一些保护措施会检查请求中具有相同名称的2个cookie,然后服务器将解码cookie的名称。
Cookie炸弹
Cookie Tossing攻击也可以用于执行Cookie炸弹攻击:
Cookie Bomb防御措施
在cookie名称中使用前缀__Host
__Host
如果cookie名称具有此前缀,只有在标记为安全,从安全来源发送,不包括Domain属性,并且Path属性设置为/的情况下,它才会被接受在Set-Cookie指令中
这可以防止子域强制将cookie发送到顶级域,因为这些cookie可以被视为“锁定域”
参考资料
最后更新于