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

时间:2018-11-06 17:12:43

标签: django csrf django-channels

我已经使用Django频道(v。2.1.5)在支持Django(v。2.0)的网站上成功创建了一个网络套接字。

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

我知道这是一个很开放的问题,但是我找不到任何具体的解释,如果有人对我的解释更重要的话。

干杯!

1 个答案:

答案 0 :(得分:2)

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

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

恶意网站也有可能打开与其他网站的websocket连接。这就是为什么必须使用OriginValidator的原因。如果使用它,则服务器仅接受来自您的网站的websocket连接。

当恶意站点试图打开与您服务器的连接时,它将立即被拒绝。

因此,后请求和Websocket连接之间的区别在于,浏览器在websocket连接上发送了原始报头,但并非总是在后请求上发送。

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

因此,也许您根本不需要使用CSRF-cookie。另请参阅:CSRF protection with CORS Origin header vs. CSRF token