检查引荐来源网址是否足以防止跨站点请求伪造攻击？我知道引荐来源网址可能会被欺骗，但是攻击者有没有办法为客户端做到这一点？我知道代币是常态，但这行得通吗？
最佳答案
这是一个 3 年前的问题，有四个不同的答案，基本上说明了同一件事:遵循规范，使用 token ，不要尝试使用引用者。
虽然 token 仍然被认为是最安全的选项，但使用引用者通常要容易得多，而且也非常安全。请务必查看所有 PUT/POST/PATCH/DELETE 请求，如果引用者丢失或来自错误的域，则将其视为攻击。很少有(如果有的话)代理会删除此类请求的引荐来源网址。
另请参阅OWASP recommendation关于检查 Referer header 作为 CSRF 保护:
Checking The Referer Header
Although it is trivial to spoof the referer header on your own browser, it is impossible to do so in a CSRF attack. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state. This makes a referer a useful method of CSRF prevention when memory is scarce.
However, checking the referer is considered to be a weaker from of CSRF protection. For example, open redirect vulnerabilities can be used to exploit GET-based requests that are protected with a referer check. It should be noted that GET requests should never incur a state change as this is a violation of the HTTP specification.
There are also common implementation mistakes with referer checks. For example if the CSRF attack originates from an HTTPS domain then the referer will be omitted. In this case the lack of a referer should be considered to be an attack when the request is performing a state change. Also note that the attacker has limited influence over the referer. For example, if the victim's domain is "site.com" then an attacker have the CSRF exploit originate from "site.com.attacker.com" which may fool a broken referer check implementation. XSS can be used to bypass a referer check.
关于security - 检查引荐来源网址是否足以防范 CSRF 攻击？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1413930/