使用Django和websockets跨站点请求伪造保护
我已经使用Django频道（2.1.5版）在Django（2.0版）支持的网站上成功创建了websocket。
一切都很好，但我想知道CSRF代币怎么样。如果是WebSocket，是否需要它？文档中说，使用OriginValidator来防止这种线程已经足够了，但我想确保这一点。我是说，CSRF令牌发生了什么？我只是通过安全通道发送数据，而没有它，后端自动检查一切吗？如果是这样，为什么？为什么简单视图不能做到这一点？
我知道这是一个悬而未决的问题，但我找不到任何具体的解释，如果有人有一个我会非常感激的解释。
干杯
共有1个答案
使用websocket连接时不需要CSRF令牌。
当您访问恶意网站时，它可能会通过javascript向您当前登录的另一个网站发送post请求。您的浏览器还会将会话cookie发送到另一个网站，因此Web服务器认为您确实愿意发送此post请求，并将执行该请求。CSRF cookie可以防止这种情况。Thins恶意站点无法读取CSRF cookie的值，它无法将该值添加到post请求。
恶意网站也可能打开与其他网站的websocket连接。这就是为什么必须使用OriginValidator的原因。如果您使用它，那么服务器只接受来自您站点的websocket连接。
当恶意网站试图打开到您服务器的连接时，它会立即被拒绝。
因此，post请求和websocket连接之间的区别在于，浏览器在websocket连接上发送一个原始标头，但并不总是在post请求上发送。
现代浏览器似乎总是发送源标题：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin
因此，也许你根本不必使用CSRF cookie。另请参见：使用CORS原始标头的CSRF保护与CSRF令牌
-
CSRF 中间件和模板标签提供对跨站请求伪造简单易用的防护。某些恶意网站上包含链接、表单按钮或者JavaScript ，它们会利用登录过的用户在浏览器中的认证信息试图在你的网站上完成某些操作，这就是跨站攻击。还有另外一种相关的攻击叫做“登录CSRF”，攻击站点触发用户浏览器用其它人的认证信息登录到其它站点。 防护CSRF 攻击的第一道防线是保证GET 请求（以及在9.1.1 Safe Method
-
CSRF攻击迫使经过身份验证的用户(受害者)发送伪造的HTTP请求，包括受害者的会话cookie到易受攻击的Web应用程序，这允许攻击者强制受害者的浏览器生成请求，以便易受攻击的应用程序感知来自受害者。 我们下面来了解这个漏洞的威胁代理，攻击向量，安全弱点，技术影响和业务影响。 威胁代理 - 任何人都可以将内容加载到用户的浏览器中，从而迫使他们向您的网站提交请求。 攻击者的方法 - 攻击者创建伪造
-
跨站请求伪造（CSRF）是一种漏洞利用，攻击者致使受害的最终用户按恶意URI（例如以误导的链接、图片或重定向提供给用户代理）到达受信任的服务器（通常由存在有效的会话Cookie而建立）。 针对客户端的重定向URI的CSRF攻击允许攻击者注入自己的授权码或访问令牌，这将导致在客户端中使用与攻击者的受保护资源关联的访问令牌而非受害者的（例如，保存受害者的银行账户信息到攻击者控制的受保护资源）。 客户端
-
跨站请求伪造(Cross-site request forgery)， 简称为 XSRF，是 Web 应用中常见的一个安全问题。前面的链接也详细讲述了 XSRF 攻击的实现方式。 当前防范 XSRF 的一种通用的方法，是对每一个用户都记录一个无法预知的 cookie 数据，然后要求所有提交的请求（POST/PUT/DELETE）中都必须带有这个 cookie 数据。如果此数据不匹配 ，那么这个请求
-
2.5. 跨站请求伪造 跨站请求伪造(CSRF)是一种允许攻击者通过受害者发送任意HTTP请求的一类攻击方法。此处所指的受害者是一个不知情的同谋，所有的伪造请求都由他发起，而不是攻击者。这样，很你就很难确定哪些请求是属于跨站请求伪造攻击。事实上，如果没有对跨站请求伪造攻击进行特意防范的话，你的应用很有可能是有漏洞的。 请看下面一个简单的应用，它允许用户购买钢笔或铅笔。界面上包含下面的表单： COD
-
描述 跨站请求伪造，或 CSRF 攻击，在恶意网站、电子邮件、即使消息、应用以及其它，使用户的 Web 浏览器执行其它站点上的一些操作，并且用户已经授权或登录了该站点时发生。这通常会在用户不知道操作已经执行的情况下发生。 CSRF 攻击的影响取决于收到操作的站点。这里是一个例子： Bob 登录了它的银行账户，执行了一些操作，但是没有登出。 Bob 检查了它的邮箱，并点击了一个陌生站点的链接。 陌生