我已经阅读了很多有关CSRF保护的信息，但是我怀疑我无法澄清，甚至在stackoverflow中也没有。
因此，我正在使用flask来构建一个Web应用程序，并且有一个名为csrf_token的函数，您可以调用该函数来生成令牌并将其放入表单（在本例中为登录表单）中作为隐藏输入。 。但是，我在想，如果攻击者进入登录站点以获取其csrf令牌，这是否会杀死站点上的csrf保护？因为这样他就可以将他的csrf令牌附加到ajax请求上，这基本上等于根本没有任何保护。
答案 0 :(得分：2)
您误解了CSRF的工作原理。
否，攻击者不能仅获取任何CSRF令牌。发送给不同用户的CSRF令牌不同。拿一个现有的CSRF令牌，然后用该令牌尝试用另一个令牌欺骗另一个用户会失败，因为该令牌与用户访问表单所使用的浏览器所提供的令牌不匹配。
令牌不仅会有所不同，而且CSRF令牌的要点是将令牌赋予用户两次 ，这使得攻击者无法访问两个值。 CSRF令牌既存储在cookie中（最好将HttpOnly设置为True，因此浏览器中运行的代码甚至无法访问它），并且将其嵌入表格中。提交表单后，以 形式发布的令牌必须与cookie中的令牌匹配。
因此，攻击者不仅不能使用早期的CSRF令牌（该令牌已经与用户所获得的令牌有所不同），而且攻击者也无法知道浏览器将向用户发送的Cookie，他们也永远无法即使未设置HttpOnly，也可以访问该cookie，因为域A上的攻击者无法读取域B的cookie。
大概是在这里使用Flask-WTF CSRF protection（给定函数名）。该程序包将CSRF令牌存储在Flask会话中，并通过加密方式对令牌进行签名并附加超时，因此攻击者也无法将会话替换为包含自己令牌的会话。另外，如果您的用户正在通过HTTPS访问站点，则HTTP Referer标头必须与客户端访问的主机名匹配。
关于登录表单是否特别需要使用CSRF保护的问题：是的，因为如果攻击者可以选择受害者使用的登录名，那么他们便可以访问任何东西否则受害者已经进入现场。通过保护登录表单免受CSRF攻击，可以保护用户免受这种情况的侵害。
有趣的是，我reported this issue to then-still-very-new Mozilla project in May 2000在确定了开源Zope平台上的问题之后，讨论了浏览器如何帮助缓解现在称为CSRF的问题。男孩，这让我现在觉得老了。
答案 1 :(得分：0)
以下是我对上述问题的回答。
我将分两部分回答，这两者在开始时似乎有点矛盾。但是我坚持要你读到最后。
PART 1： 默认情况下该控件已经存在，因此您无需明确地采取任何措施来保护登录页面免受CSRF的侵害。
让我们再次回顾一下基础知识。 CSRF要求在请求正文中存在一个随机令牌（通常称为“ Anti-CSRF令牌”），其唯一目的是使请求唯一，对吗？
好吧，默认情况下，登录请求中已经存在这样的令牌（尽管这并不是出于此目的，但无论如何都存在）。该令牌是用户密码。
密码使登录请求唯一。要使攻击者伪造一个伪造的登录请求并执行他打算做的一切（尽管从逻辑上讲，我无法想到他通过伪造该登录请求可以完成的任何事情），他必须知道目标用户的密码，对吗？那是极不可能的。如果知道密码，就不会使用CSRF，他会自己直接登录。
PART 2： 但是，最近我在执行Web应用程序的安全评估时遇到了一个问题。登录POST请求中有一个隐藏的随机令牌，但是显然，其目的不是减轻CSRF而是阻止密码强行实现自动化。这是他们没有临时帐户锁定/验证码的解决方法。
我写了一个小的Python脚本来克服这种情况，并且无论如何都要强行使用密码。
（如果您想尝试的话，这里是我的脚本的GitHub link。演示视频包含在README.md文件中。）
底线：
希望有帮助。如果我错了，请随时纠正我。谢谢。