JSON CSRF

JSON CSRF with FLASH (.swf) File

7 Comments

Background Information

I was trying my luck on bug bounty programs and found one interesting issue that I have exploited for the first time and it was that much interesting so thought to share with you all. This bug and way of exploiting are already available on the internet but I’ll try my best here to explain with all of the possible scenarios to make sure you’ll exploit it in your regular web application penetration testing.

CSRF with JSON Request 

To exploit CSRF vulnerability for any JSON request, below are the things that we usually check

  • Checking for any unique token present in the body of the request–> We use to remove the token and submit the request to check the CSRF.
  • Checking for any unique token present in the request headers –> We use to remove the token and re-submit the request to check the CSRF.
  • Checking Content-Type of the request header –> If the request of the body is application/json, we’ll check whether other content types are accepted or not like application/x-www-form-urlencoded and what not.
  • Checking for any referer checks –> Checking referer headers also good sometimes.

I think I have covered possible way to probe for CSRF in any JSON request. Do let me know in comment section if I missed something.

Most of the time, I have seen below mentioned protection for any JSON request

  • Unique token present in request headers
  • Content type verification to accept only “application/json

What if the unique token is not verified properly and you are able to replay the request by removing the CSRF header?

At this point, content type verification will be the alternative to protect CSRF and usually, people think this is enough protection because of the following reasons

  • Normal form based CSRF will not work because form based CSRF will be sent with content type “application/x-www-form-urlencoded ” and content-type verification will catch this.
  • If the user is able to add content type as a part of XHR (Ajax Request), then browser SOP policy will protect the CSRF actions.

If an application is only checking for “application/json” content type, these type of verifications can be bypassed easily by using Flash(.swf) file.

Exploiting case 

To work with this attack, you need following requirements on your domain (attacker’s domain).

  • Exploit Flash file: You may customise the file present here
  • Cross-domain policy file: This should be present in your domain. For my case, it’s here
  • PHP file with 307 Redirect: This also needs to be present in your domain’s root directory

I have found this vulnerability on private bug bounty program and for obvious reasons, I cannot share the name of the application

Below request was present to add the users to the application

The request contains “X-XSRF-TOKEN” as CSRF protection, but on removing this reader and the re-submitting request was working fine but on changing content type from “application/json” to something else didn’t work.

So, in order to perform CSRF, we need to find a way which contains “application/json” content type in request headers.

1.  Below are the contents of SWF file that was used as a part of exploit

Flash file contains our JSON payload with content-type “application/json” and link to PHP file that we need to send to target vulnerable application.

2. Cross-domain XML file

3. PHP file with 307 Redirect

The HTTP 307 Temporary Redirect redirect status response code indicates that the resource requested has been temporarily moved to the URL given by the Location header. The only difference between 307 and 302 is that 307 guarantees that the method and the body will not be changed when the redirected request is made.

What’s actually happened here?

The first request will be sent to attacker’s domain where .swf file is present as shown below:-

Response to this is shown below

Secondly, a POST request will submit to the PHP page with the JSON

Response to this is shown below

Next request will be

The response will be the 200 OK with user created on the application.

NOTE:- This attack will work on all browsers that support flash. I have exploited this on chrome.

Credits

  • Credits to Evgeniy Yakovchuk who created this file

 

That’s all for the day.

Stay tuned for further blogs.

 

7 comments

  1. Hello, I have understand it properly, but it didn’t work for me. Here I provided my localhost domain. i.e. januapp.com but I didn’t make request to that domain.

    Please help me out.

    package
    {
    import flash.display.Sprite;
    import flash.net.URLLoader;
    import flash.net.URLRequest;
    import flash.net.URLRequestHeader;
    import flash.net.URLRequestMethod;

    public class re extends Sprite
    {

    public function re()
    {
    var member1:Object = null;
    var myJson:String = null;
    Wonderfl.capture(stage);
    super();
    Wonderfl.capture(stage);
    member1 = new Object();
    member1 = {
    "firstName":"Avinash",
    "lastName":"thapa",
    "email":"hloloaczzzzzzker@attacker.com",
    "password":"Sup3rS3cretP@ssw0rd!!",
    "planId":"FREE_2016"
    };
    var myData:Object = member1;
    myJson = JSON.stringify(myData);
    myJson = JSON.stringify(myData);
    var url:String = "https://januapp.com/demo/test.php";
    var request:URLRequest = new URLRequest(url);
    request.requestHeaders.push(new URLRequestHeader("Content-Type","application/json"));
    request.data = myJson;
    request.method = URLRequestMethod.POST;
    var urlLoader:URLLoader = new URLLoader();
    try
    {
    urlLoader.load(request);
    return;
    }
    catch(e:Error)
    {
    trace(e);
    return;
    }
    }
    }
    }

Leave a Reply

Your email address will not be published. Required fields are marked *