JSON Web服务是否容易受到CSRF攻击?

djs*_*ith 71 security http csrf

我正在构建一个专门为其请求和响应内容使用JSON的Web服务(即,没有表单编码的有效负载).

如果以下情况属实,Web服务是否容易受到CSRF攻击?

  1. POST例如,没有顶级JSON对象的任何请求{"foo":"bar"}将被拒绝400.例如,POST具有该内容的请求42将因此被拒绝.

  2. POST具有除内容类型之外的任何请求application/json将被拒绝400.例如,POST具有内容类型的请求application/x-www-form-urlencoded将因此被拒绝.

  3. 所有GET请求都是安全的,因此不会修改任何服务器端数据.

  4. 客户端通过会话cookie进行身份验证,Web服务在通过带有JSON数据的POST提供正确的用户名/密码对后为其提供,例如{"username":"user@example.com", "password":"my password"}.

补充问题:是PUTDELETE要求日益容易受到CSRF?我问,因为似乎大多数(所有?)浏览器都不允许HTML表单中的这些方法.

编辑:添加了第4项.

编辑:到目前为止,有很多好的评论和答案,但没有人提供过这种Web服务易受攻击的特定CSRF攻击.

Gum*_*mbo 70

锻造任意CSRF请求任意介质类型实际上是唯一可能与XHR,因为窗体的方法是有限的GET和POST形式的POST邮件正文也只限于三种格式application/x-www-form-urlencoded,multipart/form-datatext/plain.但是,使用表单数据编码text/plain,仍然可以伪造包含有效JSON数据的请求.

所以唯一的威胁来自基于XHR的CSRF攻击.只有他们要么那些才会成功

如果您可以消除这两者,那么您的Web服务不容易受到CSRF的攻击.至少不是那些通过网络浏览器进行的.

  • 正如我对您的链接答案所评论的那样,我断言如果服务器不需要application/json,使用类似于http://pentestmonkey.net/blog/csrf-xml-的技术,text/plain确实可以用于JSON伪造请求后. (9认同)
  • 答案是正确的,直到今天,但很快就会出错.W3C正在考虑在HTML标准中添加enctype ="application/json":http://darobin.github.io/formic/specs/json/所以不要依赖POST主体的类型来获得持久的安全性,请使用反CSRF令牌. (8认同)
  • 草案似乎先发制人.第5节规定`application/json`表格帖子必须符合相同的原始政策,这意味着攻击不会强于XHR. (8认同)