在 CSRF 攻击中，如何无法欺骗 Referer Header？
How is it impossible to spoof Referer Header during CSRF Attack?
假设应用程序抵御 CSRF 攻击的唯一方法是检查引用 header 的同源。还假设所有浏览器都将发送引用 header（尽管情况并非总是如此）。
我读到用户欺骗自己的引用者 header 是微不足道的，但 CSRF 攻击者做同样的事情 IMPOSSIBLE。
1.) 你如何欺骗引荐来源 header？ （注意，referer headers 不能以编程方式 modified）
2.) 为什么 CSRF 攻击者不能这样做？
的确，在您的 自己的 浏览器上欺骗引用 header 是微不足道的，即使您不能以编程方式修改它们。诀窍是在浏览器发送请求之后、到达服务器之前拦截请求。
这可以使用像 Burp Suite 这样的拦截代理轻松完成。基本上你告诉浏览器使用本地拦截代理作为代理服务器。然后浏览器将向您的本地代理发出请求。本地代理将使请求保持活动状态，并允许您更改 HTTP 文本中的任何内容，包括引用 header。准备就绪后，只需释放请求，本地代理就会将其发送出去。十分简单。
另外值得注意的是，如果您不在您的网站上使用 TLS，则沿途的任何跃点都可能是邪恶的，如果他们愿意，可以修改 request/response。要了解途中的许多跃点，您可以尝试 traceroute（尽管某些路由器会简单地丢弃使 traceroute 工具工作的数据包，因此它不是可靠的测量）。
然而，在纯 CSRF 攻击的情况下，攻击者无法控制受害者的浏览器。这意味着受害者的浏览器将直接向 Web 服务器发出请求，像往常一样发送正确的引用 header。这就是为什么不可能更改受害者的推荐人 header，尽管推荐人 header 通常是糟糕的安全措施，因为它们很容易被欺骗。
总而言之，对抗 CSRF 的最佳解决方案是使用 CSRF 令牌。 OWASP recommends using the origin header and a CSRF token.
希望这对您有所帮助。如果没有，请在评论中告诉我，我会尽力澄清。
假设应用程序抵御 CSRF 攻击的唯一方法是检查引用 header 的同源。还假设所有浏览器都将发送引用 header（尽管情况并非总是如此）。
我读到用户欺骗自己的引用者 header 是微不足道的，但 CSRF 攻击者做同样的事情 IMPOSSIBLE。
1.) 你如何欺骗引荐来源 header？ （注意，referer headers 不能以编程方式 modified）
2.) 为什么 CSRF 攻击者不能这样做？
的确，在您的 自己的 浏览器上欺骗引用 header 是微不足道的，即使您不能以编程方式修改它们。诀窍是在浏览器发送请求之后、到达服务器之前拦截请求。
这可以使用像 Burp Suite 这样的拦截代理轻松完成。基本上你告诉浏览器使用本地拦截代理作为代理服务器。然后浏览器将向您的本地代理发出请求。本地代理将使请求保持活动状态，并允许您更改 HTTP 文本中的任何内容，包括引用 header。准备就绪后，只需释放请求，本地代理就会将其发送出去。十分简单。
另外值得注意的是，如果您不在您的网站上使用 TLS，则沿途的任何跃点都可能是邪恶的，如果他们愿意，可以修改 request/response。要了解途中的许多跃点，您可以尝试 traceroute（尽管某些路由器会简单地丢弃使 traceroute 工具工作的数据包，因此它不是可靠的测量）。
然而，在纯 CSRF 攻击的情况下，攻击者无法控制受害者的浏览器。这意味着受害者的浏览器将直接向 Web 服务器发出请求，像往常一样发送正确的引用 header。这就是为什么不可能更改受害者的推荐人 header，尽管推荐人 header 通常是糟糕的安全措施，因为它们很容易被欺骗。
总而言之，对抗 CSRF 的最佳解决方案是使用 CSRF 令牌。 OWASP recommends using the origin header and a CSRF token.
希望这对您有所帮助。如果没有，请在评论中告诉我，我会尽力澄清。