CSRF 令牌如何防止攻击,以及如何安全地为我的 JSON API 使用/避免它?

信息安全 Web应用程序 验证 csrf json
2021-08-10 13:11:02

我正在尝试使用 JSON 使 iOS 应用程序与 Ruby on Rails 网站进行通信。在尝试发布登录以创建用户会话时,我发现我缺少一个 CSRF 令牌。我根本不知道那是什么,所以我开始研究它,并找到了一些解决方案,如果调用格式为“application/json”,则可以删除 CSRF 保护。但这听起来会让网站容易受到攻击?

出现了一些关于 JS 表单存在相同问题的结果。那里的答案是添加到 CSRF 令牌中。经检查,它似乎也位于页眉的元内容标记中。

所以这让我感到困惑,这是我的问题:

  • 如果可以在攻击调用之前的调用中读取令牌,它如何帮助保护任何东西?恶意站点能否不简单地发出请求,解析收到的消息,然后使用令牌发送另一个请求?
  • 在登录发布操作上禁用令牌检查并让它与成功响应一起发回令牌是否安全?如果没有,有更好的建议吗?
1个回答

CSRF 攻击如何工作的总结如下:

  1. 你,这个好用户,在登录到网站 A 时,访问了其他网站的页面 B。
  2. 该页面对站点 A(您已登录)上的页面 X 执行 GET(可以是 POST,设置起来稍微复杂一点),例如 . 您的浏览器必须使用您已经过身份验证的会话/cookie
  3. 页面 X 设计导致您的帐户状态发生变化 - 经典示例是“将 X 美元转移到 B”(不太现实)或“将用户状态行设置为 PWNED”(更现实)

可以通过多种方式实现 CSRF 令牌,但其想法是,除非包含额外的更改信息(令牌),否则对状态更改 URL X 的简单 GET 请求将不起作用,例如,它必须是“X?token=123123213”。由于令牌经常合理地更改,因此上面的步骤 2 将不起作用。潜在的攻击者不知道当前的令牌。

您的问题 1 - 攻击者看不到页面 X 的内容,他只是强迫您访问它。

你的问题 2 - 因为这都是关于已经登录时的操作,所以在登录页面上不使用 CSRF 保护或多或少是可以的。但是,您可能会被迫以其他人的身份登录而不会注意到它。

http://en.wikipedia.org/wiki/Cross-site_request_forgery

更一般的问题类别是http://en.wikipedia.org/wiki/Confused_deputy_problem