CSRF攻击试图利用“站点对用户浏览器的信任”（维基百科页面如此说，而且说得好）。它是关于服务器接受来自客户端的请求，由于请求带有一些身份验证特征，这使服务器相信它来自真实用户（它确实如此）并且在真实用户的有意识控制下（它是假的）。“身份验证特征”通常是一个 cookie 值（服务器可接受），或带有基于证书的客户端身份验证的 HTTPS。

对于登录页面，服务器不信任来自客户端的请求。这就是登录页面的重点：初始化信任。登录页面需要登录名和密码，正是因为请求不会附带任何内容，这将使服务器更快乐并分散其预期的操作，即验证登录名+密码对。因此，CSRF 攻击不适用于此页面。

您仍然可以检查该Referer字段以检查“可疑业务”（如果缺少或错误，则肯定有问题），但这不会真正改变安全性。

验证它的含义是什么？引用标头：

• 可以被客户端欺骗
• 客户端可以完全省略（在通过 TOR/代理时臭名昭著）
• 不能保证用户实际上就从那里

您的浏览器出于礼貌发送了引用标头，这不是 HTTP RFC 要求。有关标头的详细信息，请参见此处：http: //www.w3.org/Protocols/HTTP/HTRQ_Headers.html#z14。

因此，很明显，此标头没有任何价值，也不应作为任何东西的保证。此外，任何足够聪明的人都可以欺骗这一点。如果您想要真正保证您的登录表单数据确实来自您的登录表单，请构建一个检查以尝试查找唯一的、随机生成的、基于用户（或基于导航器）的值。这将比 Referer 标头更可靠（但取决于实现，不一定是防弹的）。

对于登录表单 - 不是那么多。最可能发生的情况是，像 Facebook 这样的知名网站可能会变得流氓，并使用他们客户的机器（通过来自由 javascript 触发的嵌入式表单的 POST 请求）作为类似僵尸网络的实体的一部分来暴力破解您的登录表单。

但这不太可能，所以在登录时不检查引荐来源是没有问题的。

请注意，网站的其余部分，在登录后，应该检查任何类型的请求（GET 或 POST）的引荐来源网址有副作用。否则，我可以创建一个具有嵌入式 iframe 的网站，其内容如下：

<form method=post action="www.yoursite.com/makepayment.php">
<input type=hidden name="to" value="123453323">
<input type=hidden name="amount" value="$10000">
</form>

和 JS 触发表单，提交一个 POST 请求，将钱从你转移给我（或其他）。

您想避免这种情况，因此请检查那里的推荐人。

更好的是，在<input type=hidden>具有副作用的页面上的每个表单中使用 CSRF 令牌（在一小段时间内附加到特定帐户的临时令牌）（即，不仅加载新页面，而且还会发生变异存储在服务器或其他地方的数据）