使用 Django 和 websockets 进行跨站点请求伪造保护

Posted 2023-03-03

【中文标题】使用 Django 和 websockets 进行跨站点请求伪造保护

【英文标题】：Cross Site Request Forgery protection with Django and websockets

【发布时间】：2019-04-10 03:12:00

【问题描述】：

我已经使用 Django 通道 (v. 2.1.5) 在我的 Django(v. 2.0) 驱动的网站上成功创建了一个 websocket。

一切都很好，但我想知道 CSRF 令牌怎么样。在 websockets 的情况下是否需要它？ Documentation 说使用 OriginValidator 来防止这样的线程就足够了，但我想确保这一点。我的意思是，CSRF 代币发生了什么？我只是在没有它的情况下通过安全通道发送数据，后端会自动检查所有内容吗？如果是这样，那为什么？为什么简单的视图不能做到这一点？

我知道这是一个非常开放的问题，但我找不到任何具体的解释，如果有人有的话，我会非常感激。

干杯！

【参考方案1】：

使用 websocket 连接时不需要 CSRF 令牌。

当您访问恶意网站时，它可能会通过 javascript 向您当前登录的另一个网站发送 post-request。您的浏览器也会将会话 cookie 发送到该其他网站，因此网络服务器认为您确实愿意发送此后期请求并将执行该请求。 CSRF-cookie 可以防止这种情况。使恶意站点无法读取 CSRF-cookie 的值，因此无法将值添加到 post-request。

恶意网站也有可能打开到不同网站的 websocket 连接。这就是为什么您必须使用 OriginValidator 的原因。如果你使用它，那么服务器只接受来自你的站点的 websocket 连接。

当恶意网站尝试打开与您服务器的连接时，它会立即被拒绝。

因此，post-request 和 websocket-connections 之间的区别在于，浏览器在 websocket 连接上发送原始标头，但并不总是在 post 请求上。

现代浏览器似乎总是发送原始标头：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin

所以也许你根本不需要使用 CSRF-cookie。另见：CSRF protection with CORS Origin header vs. CSRF token