Dropbox采用传统的跨站攻击防御手段，但我们也使用相同的网站Cookie作为对新型浏览器的深度防御手段。在这篇文章中，我们描述了如何在Dropbox上推出基于同站点cookies的防御，并提供了一些关于如何在您的网站上执行相同操作的指导。

背景

最近，IETF（国际互联网工程任务组）发布了一个介绍同站点cookies的新版RFC。与传统Cookie不同，浏览器不会在跨站点请求中发送同站点cookies。 Dropbox最近开始使用同站点cookies技术来防止CSRF攻击和跨站点信息泄露。有此我们得出结论，同站点cookies技术是减少网站遭受攻击概率的便捷方式。

跨站请求

网络上的许多攻击涉及跨站点请求，包括众所周知的跨站请求伪造（CSRF）攻击。这种攻击可以诱骗让受害者的浏览器对受信任的网站进行无意的请求。由于用户信任Dropbox并在Dropbox上保存有很多敏感的数据，因此我们对于这类攻击尽可能的强化防显得御至关重要。

什么是CSRF攻击？举个栗子，让我们假装Dropbox天真地不会防范CSRF攻击。受害者访问攻击者控制的网站时，袭击开始，如476K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3g2$3K9h3I4Q4x3X3g2U0L8$3@1`.。然后这个网站返回带有恶意加载数据的页面。浏览器将会执行这些恶意加载数据，它会发起如442K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6V1M7X3!0H3j5X3!0^5i4K6u0W2j5$3!0E0i4K6u0r3j5$3#2V1i4K6u0r3k6r3g2D9k6i4c8W2的请求并尝试删除用户数据。

一个假象的针对Dropbox的CSRF攻击

经典的针对CSRF的防御方法是引入随机值令牌（称为CSRF令牌），并将其值存储在cookie中，称为csrf_cookie，在第一页加载。浏览器在每次“不安全”请求（POSTS）中发送CSRF令牌作为请求参数。然后，服务器将csrf_cookie的值与请求参数进行比较，如果这些值不匹配，则会抛出一个CSRF错误。

即使网站具有CSRF防御功能，也可能容易受到跨站信息泄露攻击（如跨站搜索攻击和JSON劫持）。 例如，假设33dK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3c8J5L8%4m8T1L8%4S2Q4x3X3g2U0L8$3@1`.有一个AJAX路由/ get_files。 对/ get_files的GET请求将获取所有登录用户的文件名， 响应的大小则可能引起一些侧面信息（例如用户的Dropbox中有多少文件）的泄漏。

我们现在来描述一下如何设计和使用同站点cookies技术来防御针对Dropbox的跨站点攻击。

设计

为了可靠性和安全性，我们对同站点cookies保护方案的设计应具有以下要求：

l  CSRF防御：提供的防御应等同于我们现有的CSRF防御：所有POST请求（默认情况下）必须是同站点请求，因为它们状态随时发生变化。 GET请求不需要任何CSRF保护，但可能仍需要对不同类型的跨站漏洞负责（请参阅下一个要求）。

l  跨站点信息泄漏防御：AJAX 中的GET请求应该是同站点的，因为它们是许多跨站点信息泄漏漏洞的源头。

l  可用性：我们的设计的保护手段应该经过仔细推敲的并容易复原。 我们仍然会保持现有的CSRF防御，因为同站点Cookie保护技术只是一种防御加固手段。 此外，在实行该技术时，我们不应该破坏有效的跨站点GET请求（例如通过电子邮件共享的Dropbox链接）的现有行为。

l  灵活性：我们的设计应该是可扩展的，以允许在各种请求类型和路由上进行跨站防御，而不仅仅是POST请求和AJAX GET请求。

通过将SameSite属性设置为两个值（严格或松散）中之一，可以使Cookie变为同站点的。 严格情况下，浏览器不会在任何跨站点请求上发送同站点cookie。当不那么严格时，浏览器只阻止在“不安全”请求（POST）中发送同站点cookie，但将允许“安全”请求（GET）发送。

假设Dropbox存储两个cookie：一个session_cookie和一个csrf_cookie（我们正在简化）。

此外，Dropbox站点上的db5K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6V1M7X3!0H3j5X3!0^5i4K6u0W2j5$3!0E0i4K6u0r3j5h3A6S2P5q4)9#2k6X3I4G2k6$3W2F1的POST请求将输用户的凭据作为输入，然后允许用户登录（或同样地，写入session_cookie）。Dropbox在页面上也有许多“共享链接”，格式为434K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6V1M7X3!0H3j5X3!0^5i4K6u0W2j5$3!0E0i4K6u0r3M7$3S2Q4x3V1k6Q4x3X3g2Q4x3X3g2Q4x3X3g2Q4x3V1k6X3K9h3I4W2L8X3q4E0k6b7`.`.。 用户可以通过电子邮件分享这些链接，并限制对这些链接的访问。

在对如何向Dropbox添加同站点Cookie保护进行头脑风暴时，我们提出了以下天真的设计，但很快就弄清楚他们有缺陷：

l  将强制登录模式中的SameSite属性添加到session_cookie中。这使得所有请求都登录到同一站点，并针对所有经过身份验证的用户的CSRF和交叉信息泄漏进行辩护。 不幸的是，在用户通过电子邮件共享的链接对Dropbox 进行访问的情况下，这可能是有问题的。 上述情况下，通过身份验证的用户的跨站GET请求可能与预期不同，因为浏览器将不会发送该cookie。

候选设计方案1：Dropbox在强制登录模式下给会话cookie添加同站点属性

方案1并不理想，因为好的跨站GET请求将要求用户重新登录（即使该用户已经登录）

l  在松散模式而非强制模式下使用session_cookie。如前所述，这只会提供基本的CSRF保护，并且也不能防御交叉源信息泄漏攻击（如跨站搜索攻击和使用AJAX GET请求的JSON劫持）。此外，它比我们已有的CSRF保护更弱，因为它不为未经身份验证的用户提供保护（例如，它不提供对登录CSRF攻击的防御）。

候选设计方案2：Dropbox在松散登录模式下给会话cookie添加同站点属性。这样CSRF防御只能用于认证请求，例如第一个登录请求可能是跨站请求。

l  在强制登录模式下，将CSRF cookie（csrf_cookie）作为同站点cookie。然而，这使得逐步发现及应对意外故障变得更加困难。此外，为避免会话固定我们会以加密方式将CSRF令牌绑定到session_cookie上，这将导致这种设计方案不起作用。当我们看到session_cookie时，实际上csrf_cookie是缺失或无效的，此时我们会怀疑会话被固定并将用户登出。因此，简单的跨站点GET请求都将失败。

候选设计方案3：Dropbox在强制登录模式下给CSRF cookie添加同站点属性。

[培训]科锐逆向工程师培训第53期2025年7月8日开班！