检查引荐来源网址是否足以防止跨站点请求伪造攻击？我知道引用者可以被欺骗，但是攻击者有什么办法可以为客户做到这一点？我知道代币是常态，但这行得通吗？
问问题
25542 次
6 回答
47
这是一个 3 岁的问题，有四个不同的答案，基本上说明了同一件事：遵循规范，使用代币，不要尝试使用推荐人。
虽然令牌仍然被认为是最安全的选项，但使用引用者通常要容易得多，而且也非常安全。只要确保查看所有 PUT/POST/PATCH/DELETE 请求，并在缺少引用者或来自错误域的情况下将其视为攻击。很少有（如果有的话）代理会删除此类请求的引用者。
另请参阅OWASP关于检查引用标头作为 CSRF 保护的建议：
检查Referer Header
尽管在您自己的浏览器上欺骗referer 标头是微不足道的，但在CSRF 攻击中是不可能做到的。检查引用是在嵌入式网络设备上防止 CSRF 的常用方法，因为它不需要每个用户的状态。当内存不足时，这使得引用者成为防止 CSRF 的有用方法。
但是，检查引用者被认为是 CSRF 保护的弱点。例如，开放重定向漏洞可用于利用受引用者检查保护的基于 GET 的请求。应该注意的是，GET 请求不应该引起状态更改，因为这违反了 HTTP 规范。
引用者检查也存在常见的实现错误。例如，如果 CSRF 攻击源自 HTTPS 域，则引用者将被省略。在这种情况下，当请求执行状态更改时，应将缺少引用者视为攻击。另请注意，攻击者对引用者的影响有限。例如，如果受害者的域是“site.com”，那么攻击者的 CSRF 漏洞利用源自“site.com.attacker.com”，这可能会欺骗损坏的引用检查实现。XSS 可用于绕过引用者检查。
于 2013-01-04T07:43:56.817 回答
11
除此之外，对于浏览器（或公司代理）不发送推荐人的用户，使用引荐来源网址将不起作用。
于 2009-09-12T01:16:31.817 回答
7
唯一正确的答案是“除其他事项外，对于浏览器（或公司代理）不发送推荐人的用户，使用引荐来源网址将不起作用。” 话虽如此，这在当今非常罕见。所有说推荐人可以伪造的人都充满了它。除非您以其他方式（XSS/特洛伊木马/等）控制他人的浏览器，否则您不能伪造推荐人。如果您需要推荐人来使用应用程序，它们与 CSRF 令牌一样有效。只需确保您 100% 确保您的检查是正确的（例如，如果您使用正则表达式，请确保您从推荐人的开头“^”开始检查）。
于 2013-02-07T15:04:05.740 回答
0
是的。 如果你采取一些预防措施。
这是一个 12 岁的问题，这是第一个出现的结果，所以我要回答它。在这 12 年里，情况发生了很大变化。因此，虽然当时它可能是一个糟糕的选择，但现在它是一个易于实施且可靠的解决方案。
使用referrer 的主要疑问是请求中是否没有referrer 标头。这可能发生在多种情况下，例如攻击者省略引荐来源网址，从安全页面请求不安全页面，代理或用户选择忽略它或通过元标记忽略它。
在上述所有情况下，您都应该严格忽略并在没有有效推荐人的情况下失败请求。很明显，当攻击者省略标头时您会失败，而您根本不能在页面的元标记中省略它。如果用户决定选择忽略它，那是他们的选择，它会破坏功能，就像禁用 cookie 或 javascript 会破坏大多数网站一样。
从安全页面向不安全页面发送请求也不是什么大问题。因为在这12年里。网络发生了很大变化，大多数网站实际上根本不需要处理不安全的端点，如果你这样做，你就不会在地址栏中出现那个确保锁定的标志。
谈到安全端点，也不用担心代理或 ISP 会忽略标头，因为包括标头在内的整个请求都是加密的，拦截器根本无法检查标头，更不用说修改它们，除非他们可以访问用户的设备，这总体上使它成为一种非常罕见的情况.
但是referrer不能伪造吗？
伪造推荐人是一件既容易又困难的事情。它的可行性取决于你在这个过程中信任谁。让我们考虑一下这个可怕的策略：
用户登录网站example.com并example.com/login检查用户是否是有效用户，然后将用户重定向到example.com/sensitive，example.com/sensitive然后页面评估引荐来源网址，如果来自example.com/login，则打印敏感数据。这很糟糕，因为用户可以很容易地在他/她自己的浏览器上伪造引荐来源网址。但是防止 CSRF 攻击的整个想法不适用于您不信任用户的情况。当您不相信用户真正发送的请求时。这意味着为了伪造引荐来源网址，攻击者需要以某种方式修改用户的设备，如果攻击者拥有该访问权限，他们毕竟不会费心发送第三方请求。
所以，有什么好担心的？几乎。
有两种棘手的情况可以想到简单的解决方案。
一个。没有正确检查推荐人。这是什么意思 ？假设您的域是example.com并且您只是检查是否example.com存在于引荐来源字符串中。那么你可以错误地认为example.com.evil.com是一个真正的请求。解决方案是检查example.com/（我在我的本地 php 服务器中检查了这个并且工作正常。如果这不适用，您可能需要使用自己的环境进行测试并找到另一个解决方案）
乙。考虑到来自您自己网站的重定向。如果您的网站有一个端点可以重定向到这样的外部资源：example.com/redirect?url=extenal.com
攻击者可以利用它并发出这样的请求example.com/redirect?url=example.com/sensitive
to solve this problem it's beter not to change state (modifying database records, etc) with GET requests. as precautions you can also check if the request is from your redirect endpoint or not and also not to redirect to your own domain in your redirect endpoint.
于 2021-11-30T07:06:23.360 回答
-9
没有是不够的，攻击者很容易为客户端做到这一点，正如你所问的，攻击者所要做的就是让用户点击他创建的链接，从那时起，游戏就结束了
攻击者将复制原始站点中使用的表单，并欺骗其余部分，因为现在代码在他自己的站点上，然后将其提交到受害站点
正如您在问题中提到的，令牌是防止 CSRF 的规范
于 2009-09-12T01:14:04.313 回答
-10
遵循规范：使用代币。
检查引荐来源网址实际上什么也没做，因为无论如何请求都来自该页面！您试图阻止的问题是在用户没有做任何事情的情况下请求页面；不是被击中的页面本身。
令牌是防止这种情况的方法。您生成一个，将其存储在会话中，并将其写入 HTML，然后在发布时检查您收到的一个，看看它是否与您期望的相匹配。如果没有，你就失败了。无论哪种方式，您之后都会生成一个新令牌。
考虑到如果有多个页面，这会搞砸人们也可能是相关的；所以你可能想为每页制作一个不同的令牌。
于 2009-09-12T02:40:49.200 回答