api - CSRF token - 在大多数情况下我们需要使用它们吗?

标签 api security http csrf

因此,我基本上进行了一次史诗般的航行,以弄清楚如何实现 CSRF token 。 20 年后——现在我觉得我只是在浪费生命。哈哈

所以基本上在制作了恶意测试客户端并做了一些重新阅读之后,如果出现以下情况,它看起来几乎不是问题:

1) 你不允许过时的浏览器(它们不强制执行 CORS)

2) 您不允许通过在资源上设置“Access-Control-Allow-Origin”来允许 CORS。

3) 您使用 JSON API(所有请求-响应都发送 JSON)。

4) 您负责 XSS(他们可以注入(inject)将从同一来源运行的代码)。

所以只要你处理好 XSS(Reactjs!Holla) - 以上所有内容(我猜是减去旧的浏览器部分)基本上都是常见的做法和开箱即用的设置 - 所以看起来担心 csrf token 是浪费时间。

问题:

因此,为了避免将我的笔记本电脑扔到行驶中的汽车下 - 如果我已经遵守上述 4 种预防策略,我是否有任何理由添加 CSRF token ?


只是有趣的信息 - 想分享一个有趣的发现我的测试:

我在测试中发现的唯一证明是“GET”请求和图像标签

例如

<img src="http://localhost:8080/posts" onload={this.doTheHackerDance} />

以上将传递您的 cookie,因此成功访问端点,但显然因为它期待图像 - 它不返回任何内容 - 所以您不必进行黑客舞蹈。 :)

BUUUUT 如果该端点除了返回数据之外还做了其他事情,比如一个很好的小“GET”请求(比如更新数据)——黑客仍然可以点击“dab!”在你(抱歉病毒式舞蹈 Action 引用)。


最佳答案

tl;dr - 要求 JSON 请求可以缓解 CSRF,只要使用内容类型 header 在服务器端进行检查即可。

Do we need to use them in most cases?

在大多数其他情况下,是的,尽管有 workarounds for AJAX requests .


  1. You don't allow outdated browsers(they don't enforce CORS)
  1. You don't allow CORS by setting the "Access-Control-Allow-Origin" on the resources.

利用 CSRF 漏洞不需要 CORS。

如果 Bob 为您的站点存储了 cookie,CORS 允许您的站点允许其他站点使用 Bob 的浏览器和 cookie 从它读取

  • CORS 削弱了 Same Origin Policy - 它不会增加额外的安全性。
  • Same Origin Policy (通常 - 请参阅下面的警告)不会阻止向服务器发出请求,它只是停止读取响应。
  • Same Origin Policy不以任何方式限制非 Javascript 请求(例如 <form><img> HTML 指令发出的 POST)。
  • 不支持 CORS 的浏览器也不支持 AJAX 跨域请求。

因此,虽然出于其他原因(其他站点无法访问 Bob 的 session ),不从您的站点输出 CORS header 是好的,但这不足以防止 CSRF。

  1. You use a JSON API(all requests-responses is sending JSON).

实际上,如果您将内容类型设置为 application/json 验证此服务器端,您正在缓解 CSRF(这是上面提到的警告)。

Cross-origin AJAX requests can only use the following content-types :

  • 应用程序/x-www-form-urlencoded
  • 多部分/表单数据
  • 文本/纯文本

并且这些请求是唯一可以使用 HTML(表单标签或其他方式)发出的请求。

  1. You take care of XSS(they can inject code that will run from same origin ).

当然。 XSS 几乎总是比 CSRF 更严重的漏洞。因此,如果您容易受到 XSS 攻击,您就会遇到其他问题。

BUUUUT if that endpoint does other things besides return data like a good little "GET" request(like update data) - a hacker can still hit a "dab!" on ya (sorry for viral dance move reference).

这就是为什么 GET is designated as a safe method .它不应更改您的应用程序状态。要么按照标准使用 POST(推荐),要么使用 CSRF token 保护这些 GET。

关于api - CSRF token - 在大多数情况下我们需要使用它们吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/36998175/

相关文章:

reactjs - 使用 Node Express 作为代理服务器时,我的 React 项目中可以同时使用模拟数据和代理 api 数据吗?

对于需要来自 Azure sql 数据库的数据的端点,Azure api 在本地工作,但不能在 Azure 部署中工作。不过,具有硬编码数据的端点没问题

javascript - Angular 5 从 API 响应中省略 1.0 中的 .0

asp.net - 此站点无法提供安全连接 (ERR_SSL_PROTOCOL_ERROR)

ios - 剖析 Tinder/FB Messenger 等聊天应用程序在发送加密消息方面的作用

node.js - 如何在 HTTP 请求中发送缓冲区?

html - 什么时候可以使用 UTF-8 的?

javascript - 进入 Spotify 阵列

java - 限制对 Java Servlet 的访问

java - 如何在 JBoss 中禁用 HTTP OPTIONS 方法?