This post originated from an RSS feed registered with Web Buzz by Tim Vernum. Original Post: JavaScript Hijacking Feed Title: Secure by Design Feed URL: http://www.securearchitecture.net/feed/rss2 Feed Description: A blog about the intersection of security and architecture Latest Web Buzz Posts Latest Web Buzz Posts by Tim Vernum Latest Posts From Secure by Design

These attacks are essentially standard Cross Domain Request Forgery attacks, but they exploit two special aspects with how browsers handle JavaScript requests:

1. They are executed in the context of the calling page
2. They are not subject the "Same Origin Policy" of AJAX requests.

The first point makes JavaScript resources different to images and stylesheets, which are not executed, and therefore are mostly opaque to the calling page. (There is a small amount of information that can be leaked from the loading these kinds of resources, the JavaScript execution environment provides far more) The second point differentiates JavaScript from AJAX requests, which are entirely transparent, but only if they were made against the same domain as the containing page.

So what do these requests look like? Let's start with the most trivial example.

Attack 1

Imagine that you are writing a rich web application that holds some information about your users. A lot of your application is written in JavaScript, and in order to include the user's personal information in the pages, you dynamically generate some of the JavaScript. So you end up with a JavaScript resource like this:

user_data = { name: "John Smith", email: "john.smith@example.com" } ;

function render_page() { 
 // ...
}

and include it in your HTML file as:

<script type="text/javascript" src="app.js"></script>

That all appears to be secure - the "app.js" resource is protected behind your login page and your session management follows good security practices, so what could go wrong?

Well, this script is vulnerable to the most rudimentary form of Cross Site Request Forgery. An attacker can create a page like this:

<script type="text/javascript" src="http://www.yourdomain.com/app.js"></script>
>script type="text/javascript"<
$( function()
{
  if(user_data)
  {
    $("#email").val(user_data.email);
    $("#name").val(user_data.email);
    $("#form").submit();
  }
}
</script>

Then, if anyone navigates to the attacker's page, while they are logged into your app, then the attacker can obtain their name and email address, which will allow them to do a fairly well targeted phishing attack. And if your application contains more private data than that, then it's even worse.

But JavaScript hijacking can be even worse than that. Because a lot of web applications now deal in JSON formatted data, and JSON is (essentially) a subset of JavaScript, there are a lot of more complex requests that have the potential to open up a JavaScript hijacking vulnerability.

Attack 2

If a piece of JSON data is an array literal, such as ["John Smith", "john.smith@example.com"] or [ {name:"John Smith", email:"john.smith@example.com"} ], then it is also a valid JavaScript <script> and can be embedded inside the attackers page.

There's a bit of trickery involved in getting access to that data, but it's all described in the original JavaScript hijacking paper. The end result is that if your application uses private JSON with arrays as the top level data type, then you're almost certainly vulnerable to JavaScript hijacking attacks.

For example, if you have an AJAX request that returns a list of "friends" as a JSON array:

[
   { nickname: "John", fullname: "John Smith", page: "/view-user.php?id=14595" },
   { nickname: "Sally", fullname: "Sally Jones", page: "/view-user.php?id=19412" },
   { nickname: "Peter", fullname: "Peter Wong", page: "/view-user.php?id=10573" }
]

Then an attacker can perform a very similar attack to the email address harvesting (attack 1, above) to get a user's friends list.

This form of attack is only relevant for JSON array literals, because a standalone Object literal is not valid JavaScript, so it cannot be loaded by a >script< tag.

Attack 3

The final angle on JavaScript hijacking is the most dangerous, but thankfully is the least common - transparent cross domain request forgery.

Most CDRF attacks are blind - the attacking page makes a call into your application to initiate some nefarious action, but cannot determine whether the request was successful, due to the Same Origin Policy enforced by the browser. However, as we've shown a //