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

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

1> Aleksander B..：

---

这是一个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可用于绕过引用者检查.

2> Laurence Gon..：

---

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

---

Cheekysoft:推荐人确实很容易伪造,但这不是你不应该用它们来保护CSRF的原因.能够执行CSRF攻击的攻击者无法伪造Referer标头.

---

@Light我的评论来自近10年前,虽然是真的,但即使在那时,它可能还需要在仅限CSRF的环境中滥用浏览器插件.从2009年的苹果Flash应用程序(依赖于crossdomain.xml)或Java applet来看,这当然很容易.请参阅以下来自AleksanderBlomskøld的答案,以便更加专注地理解,考虑到更加锁定的现代浏览器.