浅谈CSRF的另类绕过之Content-Type校验绕过

Posted 2021-04-25 LE分享互联

    CSRF漏洞也是老生常谈的一个漏洞，这个漏洞和业务贴合比较近。虽然CSRF“往往”造成的危害不是很大，但有时候修复的过程也是需要耗费很多时间和精力的（尤其是在开发阶段就没考虑过）。一方面是因为如果想全站修复的话，有的代码是祖传的，无法增加全局拦截器，只能针对一些涉及增删改操作的接口逐个设置，还有的业务实现一个功能会发出大量的异步请求，这个时候如何修复就要仔细斟酌了。

不过，本期讨论的都和修复无关，我们主要交流一下后台严格验证Content-Type为 json 情况下如何绕过。

01

—

Content-Type验证

话说开发小B最近开发了一个新功能，通过手机号+短信验证码登录之后就自动注册成为会员，登录后需要设置密码，超级方便~

重点来了，因为通过手机号注册，所以设置密码的环节不需要输入原密码(通过手机注册没有设置密码环节），这时csrf漏洞的典型危害就出来了。

 阿Q激动万分，使用burp生成的csrf-poc 一顿怼，结果发现没成功，系统还抛出了鄙视：“请求失败！！！我们做了防护”

难道是验证了Referer？ 发现并不是，因为Referer随便改，重放请求依然可以成功。所以接口大概可以概括为：

POST /my/updateInfo HTTP/1.1Host: xx.comContent-Type: application/jsonReferer: https://nnn.com
{"newPassword":"YWJjMTIz","Type":"updatePassword"}

最后发现原来是验证了请求报文里面的Content-Type字段必须是application/json。对于验证了Content-Type为json的，一般的表单csrf方式肯定不行了，用xhr，js fetch 也不行，因为后台不允许跨域(即使误配置，还会涉及到浏览器的预检请求）。这个时候可以考虑Flash+307跳转的方式绕过某些系统验证header头的CSRF。

02

—

Flash和重定向

AdobeFlash可以让Web页面向用户请求使用ActionScript，而ActionScript同样可以用来设置Web请求的自定义Header。若远程站点上存在有效的crossdomain.xml文件，Flash会向不同来源的服务器发送带有自定义Header的请求。

（图来自：http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2011-February/007533.html）

为了完全避免跨域的影响，可以使用Flash来向Flash文件所在的同一服务器发送请求然后重定向并发送HTTP状态码307。307跟其他3XX HTTP状态码之间的区别就在于，HTTP 307可以确保重定向请求发送之后，请求方法和请求主体不会发生任何改变。HTTP 307会将POST body和HTTP头重定向到我们所指定的URL。

具体原理可以参考文章：

http://www.admintony.com/csrf-and-json.html

https://blog.cm2.pw/forging-content-type-header-with-flash/

03

—

Flash+307利用

先生成swf文件，也可以通过这个网址（http://cm2.pw/crossdomain ）生成POC，访问 http://cm2.pw/crossdomain ，其实就是加载了一个swf文件。

TargetURL填写，用来攻击的目标(很多文章并没提到细节，这里要注意加上redirect?status=307)

http://cm2.pw/redirect?status=307&url=https://xx.com/my/updateInfo

Header处填写：Content-Type: application/json

RequestData填写：设置密码的json报文体内容

点击Execute 之后，发现密码已经被设置了。

不难看出，首先通过返回307状态码，然后重定向到要攻击的url,

Location:https://xx.com/my/updateInfo

之后浏览器会将POST body和HTTP头(Content-Type)重定向到要攻击的url，最后发现密码已被设置。

04

—

后记

随着Flash逐渐退出历史舞台，注定会成为一个古老的利用方式。只是作为个人记录，csrf还有哪些绕过思路，也欢迎大佬们不吝赐教~