JSON Hijacking
JSON hijacking is a special version of an XSRF attack, which in certain circumstances can violate the objectives of the browser’s same origin policy. It enables a malicious web site to retrieve and process data from a different domain, thereby circumventing the “one-way” restriction that normally applies to XSRF.
The possibility of JSON hijacking arises because of a quirk in the same origin policy. Recall that browsers treat JavaScript as code, not data — they allow one web site to retrieve and execute code from a different domain. When the cross-domain code executes, it is treated as having originated from the invoking web site, and executes in that context. The reason this quirk can lead to vulnerabilities is that many of today’s complex web applications use JavaScript for transmission of data, in a way that was not foreseen when the same origin policy was devised.
JSON
JSON (JavaScript Object Notation) is a simple data transfer format that can be used to serialize arbitrary data and can be processed directly by JavaScript interpreters. It is commonly employed in Ajax applications as an alternative to the XML format originally used for data transmission. In a typical situation, when a user performs an action, client-side JavaScript uses XMLHttpRequest to communicate the action to the server. The server returns a lightweight response containing data in JSON format. The client-side script then processes this data and updates the user interface accordingly. For example, an Ajax-based web mail application may contain a panel allowing users to tab between different data. When a user clicks the Contacts tab, the browser uses XMLHttpRequest to retrieve the user’s personal contacts,
which are returned using JSON:
[
[‘Jeff’, ‘1741024918’, ‘ginger@microsoft.com’ ],
[‘C Gillingham’, ‘3885193114’, ‘c2004@symantec.com’ ],
[‘Mike Kemp’, ‘8041148671’, ‘fkwitt@layerone.com’ ],
[‘Wade A’, ‘5078782513’, ‘kingofbeef@ngssoftware.com’ ]
]
The returned message contains valid JavaScript syntax that defines an array. The client-side script uses the JavaScript interpreter to construct the array and then processes its contents.
Attacks against JSON
Because JavaScript is being used to transmit data, rather than pure code, the possibility arises for a malicious web site to exploit the same origin policy’s handling of JavaScript and gain access to data generated by other applications. This attack involves an XSRF request, as described previously. However, in the present case, it may be possible for the malicious site to read the data returned in the cross-site response, thereby performing two-way interaction with the target application.
Of course, it is not possible for a malicious web site to simply load a script from a different domain and view its contents. That would still violate the same origin policy, regardless of whether the response in question contains JavaScript or other content. Rather, the malicious web site uses a <script> tag to include the target script and execute it within its own page. With a bit of work, by actually executing the included script, the malicious site can gain access to the data it contains.
At the time of this writing, there are two known ways in which a malicious site can perform this trick: by overriding the default array constructor or by implementing a suitable callback function.
Overriding the Array Constructor
If the JSON data returned by the target application contains a serialized array, the malicious web site can override the default constructor for arrays in order to gain access to the JSON data when the array is constructed. This attack can be performed as follows in the Firefox browser:
<script>
function capture(s) {
alert(s);
}
function Array() {
for (var i = 0; i < 3; i++)
this[i] setter = capture;
}
</script>
<script src=”http://wahh-app.com/private/contacts.json”></script>
This proof-of-concept attack performs three key actions:
■ It implements a function called capture , which simply generates an alert displaying any data passed to it.
■ It overrides the Array object and defines the setter for the first three elements in the array to be the capture function.
■ It includes the target JSON object within the page by setting the rele vant URL as the src attribute of a <script> tag.
When this attack is executed, the target of the <script> tag is retrieved and executed. The serialized object, which is a multidimensional array containing the victim user’s contacts, is constructed. When each element in the array is set, the overridden setter is invoked, enabling the attacker’s script to capture the contents of the element. In the example, the script simply displays a series of alerts containing the array data.
This exact vulnerability was discovered within the GMail application by Jeremiah Grossman in 2006. In other instances, attacks can override Object rather than Array , with the same effect.
Implementing a Callback Function
In some applications, the JavaScript returned by the vulnerable application does not contain only a JSON object, but also invokes a callback function on that object. For example:
showContacts(
[
[ ‘Jeff’, ‘1741024918’, ‘ginger@microsoft.com’ ],
[ ‘C Gillingham’, ‘3885193114’, ‘c2004@symantec.com’ ],
[ ‘Mike Kemp’, ‘8041148671’, ‘fkwitt@layerone.com’ ],
[ ‘Wade A’, ‘5078782513’, ‘kingofbeef@ngssoftware.com’ ]
]);
This technique is often used in mash-ups in which one application includes a JSON object from another domain, and specifies a call-back function in its request for the script. The returned script invokes the specified call-back function on the JSON object, enabling the invoking application to process the data in arbitrary ways.
Because this mechanism is specifically designed to work around the browser’s same origin restrictions, it can of course be abused by an attacker to capture data returned from other domains. In the example shown, an attack simply needs to implement the showContacts function and include the target script. For example:
<script>
function showContacts(a) {
alert(a);
}
</script>
<script src=”http://wahh-app.com/private/contacts.json?callback=
showContacts”></script>
Finding JSON Hijacking Vulnerabilities
Because JSON hijacking is a species of cross-site request forgery, some instances of it can be identified using the same methodology as was described for XSRF. However, because JSON hijacking allows you to retrieve arbitrary data from another domain, and not only perform cross-domain actions, you are interested in a different range of functionality than you are when probing for standard XSRF flaws.
Preventing JSON Hijacking
As already described, there are several preconditions that must be in place before a JSON hijacking attack can be performed. To prevent such attacks, it is necessary to violate at least one of these preconditions. At the time of this writing, each of the following countermeasures should be sufficient to frustrate a JSON hijacking attack. However, research into these attacks is thriving. To provide defense-in-depth, it is recommended that multiple precautions are implemented jointly.
■ The application should use standard anti-XSRF defenses to prevent cross-domain requests for sensitive data. Requests for JSON objects should include an unpredictable parameter that is verified before the data is returned.
■ When an application retrieves JSON objects from its own domain, it is not restricted to using <script> tags to include the objects. Because the request is on-site, client-side code can use XMLHttpRequest to gain unfettered access to the response data and perform additional processing on it before it is interpreted as JavaScript. This means that the application can insert invalid or problematic JavaScript at the start of the response, which the client application removes before it is processed.
This is how Google prevented the attack described against GMail, by inserting the following at the start of the returned script:
while(1);
■ Because the application can use XMLHttpRequest to retrieve JSON data, it can use POST requests to do so. If the application accepts only POST requests for JSON objects, it will prevent third-party sites from including them via <script> tags.
NEXT is..Session Fixation……………………………,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
