您会将以下情况视为（危险的）CSRF 吗？

Question

想象一下你有一个很大的合作。现在有人发现了 CSRF 漏洞，它只能通过自己的站点起作用（因为该站点通过检查 Referer-Header 来保护，没有 CSRF 令牌）。这可以执行关键操作，但前提是请求来自您的站点。这意味着小型 XSS 攻击可以通过此漏洞执行更大的操作。您是否将此视为严重漏洞，是否应将其视为 CSRF 攻击？

Answer 1

这被称为 On Site Request Forgery。

XSS 漏洞总是胜过任何 CSRF/OSRF 攻击。试想一下，如果表单不受 referer 保护，而是受令牌保护，XSS 攻击可以简单地从 DOM 中读取令牌，然后提交表单。

因此，网站没有额外的风险。唯一的例外是 Open Redirect Vulnerability 与作为 GET 实现的不安全操作相结合。

说以下 URL 可用：

https://example.com/delete_my_account

处理程序验证引用以确保请求来自 https://example.com/*。

然而，还有另一个 URL 可用的问题 JavaScript 重定向：

https://example.com/redirect_to_site

这将在站点内按如下方式调用以跟踪外部链接：

https://example.com/redirect_to_site?https://google.com

然而，通过构建重定向到如下内容的 CSRF 攻击，OSRF 攻击是可能的：

https://example.com/redirect_to_site?https://example.com/delete_my_account

因为 referer 被检查，这将验证请求，因为只有 delete_my_account 在这里检查 referer，因为这被认为是不安全的操作。但是，因为它可以通过未受保护的处理程序重定向，它可以击败引用保护。

因此，除非网站上有这样的功能，或者除非网站允许用户内容构建这样的链接，否则不存在检查引荐来源以进行 CSRF 保护的漏洞。

注意： 在任何人提到 referer header 可以被欺骗之前，这只能通过攻击者自己的连接实现。在 CSRF 攻击中，您需要在受害者的连接上进行欺骗 - CSRF 是针对另一个用户的攻击 - 因此，尽管 refererer 的保护较弱，但在许多情况下它仍然足够。

您会将以下情况视为（危险的）CSRF 吗？

Would you count following scenario as (dangerous) CSRF?

security

xss

csrf