Y0gi here back again with another interesting blog .In this blog i am going to talk about JSON CSRF , something which you have might heard or not but you don’t come across this often or haven’t seen much people talking about this … So what the fuck is this JSON CSRF?
Before diving into that let’s take a quick look of What CSRF is ?
Cross-site request forgery (also known as CSRF) is a web security vulnerability that allows an attacker to induce users to perform actions that they do not intend to perform. It allows an attacker to partly circumvent the same origin policy, which is designed to prevent different websites from interfering with each other.
And What can be it’s Impact ?
An Adversary can carry out CSRF attack to modify the details of a victim and also can take over the victim Account. .Also atatcker can buy goods ,add something to victim’s shopping cart ,disable 2FA etc
If you want to know CSRF in more details then please refer to https://portswigger.net/web-security/csrf
https://owasp.org/www-community/attacks/csrf
Now What ’s the deal with JSON CSRF?
It’s nothing much different ; In JSON CSRF the data sent to the server is in JSON format and the Content-Type is Content-Type: application/json, now the problem is that we can’t send Content-Type: application/json, using a regular HTML form, it is only possible through an XMLHTTP Request or in simple words through an AJAX requests to the server, but due to CORS policy we can’t do that unless the server allows over custom Origin and Access-Control-Allow-Credentials: true is set in the response.
Let’s look at a request to understand the scenario better
So what’s going on ; {“id”:1025274966 …..} the data is sent in the form of json format instead of id=1025274966… ,
You can’t create a proof of concept like the one normally you create ,or by using Burp enagagement tools , to create CSRF poc
So What to do now?
Well if we change the Content-Type from application/json to text/plain and there are no errors in the response and the form is submitted successfully than we can perform a CSRF Attack by creating an HTML Form with an attribute enctype=”text/plain”.
But Vmro what if it doesn’t accept by text/plain , then?
Now if the text/plain method is not working then we also have another option, to check if the server accepts the data in form of Content-Type: application/x-www-form-urlencoded. or application/xml
Now if the server accepts any one of these 3 then we can create a POC form like this to send the json data
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="https://site url" method="POST" enctype="text/plain">
<input type="hidden"
name='{<json data>,"padding":"'value='something"}' />
<input type="submit" value="Submit request" />
</form>
</body>
</html>Insert the json data in<json data> and the endpoint url in site url
So if the json data in site is this {“newsletter”:false,“email”:“20btbeaexs@popcornfarm7.com”,“name”:“Y0gi”} the line should be ‘{“newsletter”:false,“email”:“20btbeaexs@popcornfarm7.com”,“name”:“Y0gi”,“padding”:“‘value=‘something”}’ in the form
Trick: Sometimes the url endpoint remain confusing , mostly in case of api endpoint ,so you can check through burp csrf poc generator , what will be the url in the form
Note: All of this is only possible if there is no Anti-CSRF protection token or some other CSRF protection mechanisim.
So still now what’s going on ? that lead to our bypass
Actually Server was looking for json formatted data but don’t validate the Content-type that’s why we were able to send the request by different methods
But What if Server looking for json formatted data and validate the Content-type as well, i.e application/json?
Now things are getting really really complex here ,If the Server is validating the Content-type what we should do now ? Is it a dead-end for us?
But
Here even if application is validating the Content-type and data format, this attack can be achieved using flash and 307 redirect.
First we will need a specially crafted crafted SWF 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.
2nd we gonna need a 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.
Next we need a PHP File with 307 Status Code
<?php// redirect automaticallyheader("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.
That’s it ,this CSRF issue is quite complex and in lot of cases using flash for browser is Out Of Scope ,so carefully read the scopes of programs if you have encountered this scenario
This method of CSRF is originally posted by https://twitter.com/emgeekboy .So kudos to the pro
One interesting thing i wanna share is the first valid CSRF that I found is json-csrf ,and i also got Hall Of Fame due to it ….
Anyway if you like this writeup and if it proves to be helpful for you like and upvote this post
Want to get updates about my cybersec journey .follow me on twitter https://twitter.com/AnonY0gi
