有没有理由为啥 Web 开发人员不使用 CSRF 作为登录页面

Posted 2023-03-10

【中文标题】有没有理由为啥 Web 开发人员不使用 CSRF 作为登录页面

【英文标题】：Are there reason why web devs dont use CSRF for login pages有没有理由为什么 Web 开发人员不使用 CSRF 作为登录页面

【发布时间】：2016-05-12 02:24:42

【问题描述】：

我最近意识到我正在运行一些生产 Web 应用程序。登录页面没有csrf保护。

只有在身份验证之后才会启动 csrf 保护。

我只是想知道开发人员/管理员是否有理由这样做。可能是由于跟踪匿名用户的负担过重吗？只是想出负载。

喜欢听大家的意见！

干杯

嘉臣：）

【问题讨论】：

还是纯属疏忽？

有些人不知道自己在做什么

【参考方案1】：

CSRF 通常旨在防止在假设用户已登录的情况下执行的攻击。例如，当用户在网上银行或信用卡帐户网站上进行会话时，恶意代码会在用户的浏览器中运行@ 987654321@

另外值得注意的是：可以为登录时需要 CSRF 做一个案例。正如here 所描述的那样，不受 CSRF 保护的登录表单留下了攻击者诱骗用户使用他们控制的帐户的可能性。在这种情况下，他们可以在使用该会话登录时收集受害者的数据或活动。所以最好在登录时添加。

【讨论】：

Paul，您描述了在登录表单的目标 url 上使用 CSRF 令牌，而不是生成登录表单的登录页面。问题是关于登录页面的 CSRF。

【参考方案2】：

当用户已经登录浏览器时，CSRF 涉及静默漏洞利用（比如说在另一个选项卡中）。

如果他不是，该请求将不会做任何事情，或者只是通过弹出登录表单来揭示攻击。

所以，为了保护愚蠢的网络用户免受伤害，是的，我想你可以尝试携带一些 antiCSRF 令牌。但是现在，告诉我你是如何再次开始反 CSRF 保护的？我怎么可能第一次在登录表单中发布我的 anticsrf 令牌？在接收登录页面时，我必须登陆 / 或其他东西才能获得 anticsrf 令牌。但大多数网站在第一个登录页面中直接有登录表单。因此，浏览器无法在第一次请求时提供 antiCSRF 令牌（不能使用 cookie，因为即使在攻击请求期间浏览器也会发送它）。

无论如何，这是我的猜测。

【讨论】：

“但大多数网站的登录表单直接在第一个登录页面”——是的，你可以像任何其他表单一样在其中放置一个带有反 CSRF 令牌的隐藏输入。 （设置一个 cookie 以及包含令牌（或包含令牌的会话）的页面，以便在提交表单时进行比较）。

这是登录过程的令牌（如 j_security_check），而不是登录页面。如果用户继续登录，恶意操作仍然可以执行。这不是增加保护。目标是甚至不呈现登录页面（或至少清除恶意请求），因为它是从另一个站点请求的。因为实际上不可行，所以请求的恶意 url 通常会在登录时被清除。如果不是，应用程序很容易受到登录受信任站点的愚蠢用户的攻击，即使他没有请求。

那么，如何防止人们在另一个域下发布成功的登录请求，例如网络钓鱼活动。

这就是我所说的“清除恶意请求”。您无法阻止他们登录（您的站点不知道它是通过攻击工作流访问的），但您的站点可以拒绝执行登录前请求的操作（并保留在一边以供登录后检索）。您知道，当您在登录后被重定向到预定位置时。

这种重定向到一个强有力的动作正是你必须牺牲的，以确保愚蠢的用户受到攻击。如果您的应用程序没有反 CSRF 令牌，它几乎不应该缓冲登录前请求。由于登录页面不应该准备令牌，因此不可能为任何有效的 url 添加书签。在没有反 CSRF 令牌的情况下，只有无效的 url（安全的只读类型）可以用于登录后重定向。无论如何，如果您的应用程序设计良好并使用 POST-redirect-GET (PRG) 模式（因为无法为 POST 添加书签），情况几乎就是如此。