What Are JSON Injections

The term JSON injection may be used to describe two primary types of security issues:

• Server-side JSON injection happens when data from an untrusted source is not sanitized by the server and written directly to a JSON stream.
• Client-side JSON injection happens when data from an untrusted JSON source is not sanitized and parsed directly using the JavaScript eval function.

What Is JSON

JSON (JavaScript Object Notation) is a lightweight data interchange format used to communicate between applications. It is similar to XML but simpler and better suited to be processed by JavaScript.

Many web applications use this format to communicate between themselves and serialize/deserialize data. Some web applications also use JSON to store important information, for example, user data. JSON is commonly used in RESTful APIs and AJAX applications.

Examples of JSON Injection Attacks

A simple server-side JSON injection could be performed in PHP as follows:

1. The server stores user data as a JSON string including the account type
2. User and password are taken directly from user input without sanitization
3. The JSON string is formed using simple concatenation: $json_string = '{"account":"user","user":"'.$_GET['user'].'","pass":"'.$_GET['pass'].'"}';
4. A malicious user appends data to their user name: john%22,%22account%22:%22administrator%22
5. The resultant JSON string is:

   {
     "account":"user",
     "user":"john",
     "account":"administrator",
     "pass":"password"
   }

6. When reading the stored string, the JSON parser (json_decode) encounters two account entries and takes the last one, granting john administrator privileges. Note that the behavior of json_decode is not incorrect – RFC-7159 states that “the names within an object SHOULD be unique” (not MUST), leaving the door open to interpretation.

A simple client-side JSON injection could be performed as follows:

1. The JSON string is the same as in the above example
2. The server gets the JSON string from an untrusted source
3. The client parses the JSON string using eval:

   var result = eval("(" + json_string + ")");
   document.getElementById("#account").innerText = result.account;
   document.getElementById("#user").innerText = result.name; 
   document.getElementById("#pass").innerText = result.pass;

4. The account value is: user"});alert(document.cookie);({"account":"user
5. The eval function executes the alert.
6. Parsing results in a Cross-site Scripting (XSS) attack (document.cookie is disclosed).

JSON Injection vs. JSON Hijacking

While JSON hijacking (a subset of Cross-site Script Inclusion – XSSI) also relates to the JSON notation, it is a slightly different attack, in some ways similar to Cross-site Request Forgery (CSRF). In the case of JSON hijacking, the attacker aims to intercept JSON data sent to the web application from the web server.

1. The attacker creates a malicious website and embeds a script tag in its code that attempts to access JSON data from the attacked web application.
2. The user, who is logged into the attacked web application, is lured to visit the malicious website (usually using social engineering).
3. Since the Same-Origin Policy (SOP) allows JavaScript from any website to be included and executed in the context of any other website, the user accesses the JSON data.
4. The malicious website hijacks the JSON data.

JSON Injection Prevention

As with most injection vulnerabilities, the key to maintaining web application security and preventing JSON injections is to sanitize data. This applies to both server-side and client-side JSON injections.

To prevent server-side JSON injections, sanitize all data before serializing it to JSON. For example, if you use Java, a good option to sanitize JSON data is to use the OWASP JSON Sanitizer.

The best method to prevent client-side JSON injections is never to use the eval function to evaluate JSON data. If you use the eval function and the untrusted data contains JavaScript code, that code will be executed. To avoid this, use JSON.parse. You can also enforce Content Security Policy, which by default prevents the use of eval.

Frequently asked questions

THE AUTHOR

Tomasz Andrzej Nidecki
Principal Cybersecurity Writer
LinkedIn

Tomasz Andrzej Nidecki (also known as tonid) is a Primary Cybersecurity Writer at Invicti, focusing on Acunetix. A journalist, translator, and technical writer with 25 years of IT experience, Tomasz has been the Managing Editor of the hakin9 IT Security magazine in its early years and used to run a major technical blog dedicated to email security.