检查引荐来源是否足以防止CSRF攻击？

Question

检查引荐来源是否足以防止跨站点请求伪造攻击？我知道引用者可能是欺骗者,但攻击者是否有办法为客户端做这件事？我知道令牌是常态,但这会有用吗？

Answer 1

这是一个3岁的问题,有四个不同的答案基本上陈述相同的事情:遵循规范,使用令牌,不要尝试使用referer.

虽然令牌仍然被认为是最安全的选择,但使用引用通常更容易,并且也非常安全.请务必查看所有PUT/POST/PATCH/DELETE请求,如果缺少引用或来自错误的域,请将其视为攻击.真的很少(如果有的话)代理删除这些类型的请求的引用.

另请参阅OWASP关于将referer标头检查为CSRF保护的建议:

检查Referer标头

尽管在您自己的浏览器上欺骗引用标头是微不足道的,但在CSRF攻击中不可能这样做.检查引用程序是防止嵌入式网络设备上的CSRF的常用方法,因为它不需要每用户状态.当内存稀缺时,这使得引用者成为CSRF预防的有用方法.

但是,从CSRF保护来看,检查引用者被认为是较弱的.例如,开放重定向漏洞可用于利用受引用检查保护的基于GET的请求.应该注意的是,GET请求永远不会发生状态更改,因为这违反了HTTP规范.

引用检查也存在常见的实现错误.例如,如果CSRF攻击源自HTTPS域,则将省略引用者.在这种情况下,当请求执行状态更改时,缺少引用程序应被视为攻击.另请注意,攻击者对引用者的影响有限.例如,如果受害者的域名是"site.com",则攻击者的CSRF漏洞源自"site.com.attacker.com",这可能会欺骗破坏的引用者检查实施.XSS可用于绕过引用者检查.

Answer 2

除其他外,使用引荐来源不适用于浏览器(或公司代理)不发送引用的用户.

Answer 3

唯一正确的答案是“除其他外，对于浏览器（或公司代理）不发送引荐来源网址的用户，使用引荐来源网址不起作用。” 话虽如此，这在当今非常罕见。所有说推荐人可以伪造的人都充满了它。除非您可以通过其他方式（XSS/特洛伊木马等）控制他人的浏览器，否则您无法伪造推荐人。如果您需要引用来供应用程序使用，它们与 CSRF 令牌一样有效。只要确保您 100% 确保您的检查是正确的（例如，如果您使用正则表达式，请确保您从推荐人的“^”开始检查）。

Answer 4

是的。 如果你采取一些预防措施。

这是一个 12 年前的问题，也是第一个出现的结果，所以我要回答它。在这12年里，事情发生了很大的变化。因此，虽然当时这可能是一个糟糕的选择，但现在它是一个易于实施且可靠的解决方案。

使用 Referrer 的主要疑问是请求中是否没有 Referrer 标头。这种情况可能会在多种情况下发生，例如攻击者省略引荐来源网址、从安全页面向不安全页面请求、代理或用户选择省略它或通过元标记省略它。

在上述所有情况下，如果没有有效的引荐来源网址，您应该严格忽略并失败请求。很明显，当攻击者省略标头时，您应该失败，并且您可以简单地不在页面的元标记中省略它。如果用户决定选择忽略它，那么这是他们的选择，并且会破坏功能，就像禁用 cookie 或 javascript 会破坏大多数网站一样。

从安全页面向不安全页面发送请求也不是什么大问题。因为在这12年里。网络已经发生了很大的变化，大多数网站根本不需要处理不安全的端点，实际上，如果您这样做，您将不会在地址栏中出现确保锁定的徽标。

谈到安全端点，也不用担心代理或 ISP 会省略标头，因为包括标头的整个请求都是加密的，拦截器根本无法检查标头，更不用说修改标头了，除非它们有权访问用户的设备，这总体上使得这种情况非常罕见。

但推荐人不能伪造吗？

伪造推荐人是一件既容易又困难的事情。它的可行性取决于您在此过程中信任的人。让我们考虑一下这个糟糕的策略：

用户登录网站example.com并example.com/login检查用户是否是有效用户，然后将用户重定向到example.com/sensitive，example.com/sensitive页面然后评估引荐来源网址，如果来自example.com/login，则打印敏感数据。这很糟糕，因为用户可以轻松地在他/她自己的浏览器上伪造引荐来源网址。但防范 CSRF 攻击的整个想法并不适用于您不信任用户的情况。这是当您不信任用户真正发送的请求时使用的。这意味着为了伪造引荐来源网址，攻击者需要以某种方式修改用户的设备，老实说，如果攻击者具有该访问权限，他们毕竟不会费心发送第三方请求。

那么，没什么好担心的？几乎。

我想到了两种棘手的情况，但都有简单的解决方案。

A。没有正确检查引荐来源网址。这是什么意思 ？假设您的域名是example.com，并且您只是检查example.com引用字符串中是否存在。那么你就可以错误地认为example.com.evil.com这是一个真实的请求。解决方案是检查example.com/SERVER_NAME 中是否包含您的域而不是整个地址。（我在本地 PHP 服务器中检查了这一点并且工作正常。您可能需要使用自己的环境进行测试，如果这不适用，请找到另一个解决方案）

B.​ 考虑来自您自己网站的重定向。如果您的网站有一个重定向到外部资源的端点，如下所示：example.com/redirect?url=extenal.com 攻击者可以利用它并发出如下请求example.com/redirect?url=example.com/sensitive

要解决此问题，最好不要使用 GET 请求更改状态（修改数据库记录等）。作为预防措施，您还可以检查请求是否来自您的重定向端点，并且不要在重定向端点中重定向到您自己的域。