0

我已经阅读了一些关于 CSRF/XSRF 的内容，其中很多似乎都在谈论 cookie，因为它们可以参与自动让用户重新登录。

所以我只是想知道如果您的网站不使用 cookie，您还需要担心使用它还是需要担心在可公开访问的表单上使用它？

我假设您仍然这样做，因为用户可能已经在浏览器中登录，然后他们可能会接触到它。

至于公共表格，显然您想要保护这些表格的唯一原因是您不希望远程站点向它们发布正确的信息！？

4

2 回答 2

1

Cross-Site-Request-Forgery，CSRF，不是针对实施 cookie 的站点的攻击，它是一种涉及使访问站点 A 的用户的浏览器调用站点 B 上的操作的能力的攻击 - 通常是他们在其中必须登录才能访问，但这不是必需的。

例如，假设您在站点 B 上有一个简单的“联系我们”表单。此表单可公开访问，无需用户登录。如果站点 A 可以通过 javascript（或 Flash 等）从客户端的浏览器提交此表单 - 那么这将被视为 CSRF，因为“联系我们”表单似乎来自从未真正访问过站点 B 的最终用户.

现在，当操作比简单的“联系我们”表单更复杂时，例如“将资金从账户 X 转移到账户 Y”，这种攻击要危险得多。这些操作通常需要用户登录到站点，该站点通常也使用某种形式的 cookie（会话 ID 作为 cookie 从浏览器来回发送到服务器）。如果没有 CSRF 保护（例如令牌），只要用户有一个主动打开的会话，就可以执行“传输”操作。但是，如果站点实际上保存了一个 cookie 以允许用户不需要每次都提交其凭据的“记住我”功能，那么 CSRF 应该能够在用户没有活动会话的情况下提交。

于 2012-10-24T14:47:53.343 回答
1

当在客户端维护任何状态并在未经用户批准的情况下提交时，跨站点请求伪造是一个问题。

用于身份验证的最常见状态示例确实是 HTTP cookie，但也存在其他示例：

  • HTTP 身份验证：基本身份验证、摘要式身份验证或集成 Windows 身份验证；基本身份验证通常用于路由器管理界面，其中许多容易受到 CSRF 的攻击。

  • HTTPS 客户端证书；

  • 边缘问题，例如使用客户端 IP 地址、HTTPS 会话 ID 或用户代理作为身份验证接受决策的不可靠部分。

如果在与相关主体相关联的提交正文中使用这些中的任何一个而没有可验证的服务器颁发的令牌，那么您就会遇到 CSRF 问题。

如果您没有任何身份验证概念，只有面向公众的表单，那么您就没有真正的 CSRF：用户 A 说服用户 B 发布公开可用的表单，如果无论如何，站点都没有做任何事情来区分来自用户 A 的提交和来自用户 B 的提交。

但是，一个开放的公共表单中没有任何服务器颁发的某种形式的令牌将更容易受到 DDoS 攻击：攻击者可以创建一个站点，迫使访问它的任何人提交表单，而不是对表单本身进行 DoS 攻击. 这会放大攻击并使其更难阻止，因为它来自许多来源。令牌也可用于防御简单形式的垃圾邮件机器人。这些不是 CSRF 问题，但可以通过相同类型的防御来缓解。

于 2012-10-24T18:33:35.997 回答