JavaScript Hijacking

Interesting paper on JavaScript Hijacking: a new type of eavesdropping attack against Ajax-style Web applications. I’m pretty sure it’s the first type of attack that specifically targets Ajax code. The attack is possible because Web browsers don’t protect JavaScript the same way they protect HTML; if a Web application transfers confidential data using messages written in JavaScript, in some cases the messages can be read by an attacker.

The authors show that many popular Ajax programming frameworks do nothing to prevent JavaScript hijacking. Some actually require a programmer to create a vulnerable server in order to function.

Like so many of these sorts of vulnerabilities, preventing the class of attacks is easy. In many cases, it requires just a few additional lines of code. And like so many software security problems, programmers need to understand the security implications of their work so that they can mitigate the risks they face. But my guess is that JavaScript hijacking won’t be solved so easily, because programmers don’t understand the security implications of their work and won’t prevent the attacks.

Tags: , , , ,

Posted on April 2, 2007 at 3:45 PM • 64 Comments

Comments

Carmelo Lisciotto • April 2, 2007 4:04 PM

The System Administrators should be the ones concerned.

Carmelo Lisciotto

Shawn Lauriat • April 2, 2007 5:13 PM

That doesn’t look new, that just looks like a specific usage of the data returned by a XSRF vulnerability, in order to more conveniently capture data the application already exposed in ways it shouldn’t.

In other words, it doesn’t really look like an attack, just a method to parse the results of an already successful CSRF attack.

pdp • April 2, 2007 5:18 PM

IMHO, this paper does not show anything that is new. In order to get any of the examples running you need to have access to the page DOM via XSS or some sort of browser bug. If the attacker has access to the page and the page DOM, of course they can hijack whatever they want.

So the title “JavaScript Hijaking” does not make sense at all, at least not to me. It is almost like saying Python hijacking or Perl hijacking. If someone has access to Python or Perl’s dynamic environment they will be able to hijack all of the objects.

This paper is primarily based on using JavaScript capabilities as programming language to show fictitious problems. Every AJAX programmer knows how to overwrite prototype methods and properties but this does not make the programming feature a security problem.

It is time to look at JavaScript the same way you look at other programming languages. There is nothing different about.

That’s all I have to say.

Good blog!

rapier57 • April 2, 2007 5:20 PM

Not just system administrators should be concerned, but web application development project leads and security administrators.

The Ajax model is the “cool” new technology on the Web, but very dangerous. I refer you to OWASP (http:// www. owasp. org/index.php/Main_Page) for more detailed information on secure web application development.

antibozo • April 2, 2007 5:25 PM

Curiously, the paper seems to deliberately avoid making the simple recommendation not to use JSON for message exchange in the first place. I’ve always been extremely wary of JSON–anything that requires calling eval on an interpolated value is something to be avoided in any language. It’s an inherently lazy and dangerous construct, and frameworks should not be promulgating it.

Nate • April 2, 2007 5:28 PM

Quote: “But my guess is that Javascript hijacking won’t be solved so easily, because programmers don’t understand the security implications of their work and won’t prevent the attacks.”

It’s actually not as bad as it could be, since very few people roll their own Ajax libraries. If Prototype and the others update, then it’s just a matter of getting people to update their libraries (which is not as difficult as updating their own code), and new builds will hopefully have new versions of the libraries.

Compare that to everybody writing do_query(“SELECT * FROM secret_data WHERE id = ” . $_GET[‘id’]) all over the place.

Josh H • April 2, 2007 5:28 PM

@pdp:

Traditional XSS attacks have concerned evil parties injecting evil code into forum posts and blog comments (or whatever) so that the code runs from the context of the application from which they want to steal data. This is crucial, because modern web browsers implement “same origin” security policies.

What’s new about this attack is that the evil code does not need to be injected into the target page. If I can direct your web app’s users to my page, and on my page I have a [script] tag with a SRC that calls your web app, your app’s JSON code will be executed in the context of my page, and I can steal any data that is delivered.

antibozo • April 2, 2007 5:38 PM

pdp> In order to get any of the examples running you need to have access to the page DOM via XSS or some sort of browser bug.

I don’t think that’s correct. Read it again. As I understand it, the attack takes advantage of the fact that any cookie-based session id will be transmitted by the browser when retrieving the protected URL embedded in the SCRIPT element contained in the attacker’s external page. The result object can then be captured by the attacker in the external context by overriding the object instantiation method.

Kragen Sitaker • April 2, 2007 5:54 PM

Quick summary for those who haven’t read the paper: if your web server will serve up private information in response to HTTP GETs, authenticated only by ambient authority like session cookies or HTTP Basic authentication, in JSON or related JavaScript formats, then third parties can use cross-host script tags to get that data into their own web page where they can read it.

A slight variation of JSON is usually the most convenient way to get data into AJAX pages, so it’s used with AJAX a lot, but it’s not a strictly AJAX technique; it’s a perfectly good format for getting data from Perl into Python or Ruby into PHP. So this isn’t a strictly an attack on AJAX applications; AJAX is vague enough that that probably isn’t possible.

The paper does argue that any client-side framework requires your server to be vulnerable to this attack, but it is wrong. First, the client-side framework can’t require you to store private data on your server; second, none of the client-side frameworks I’m familiar with (not all of them, admittedly) make such stringent demands on the design of your server URLs that it is impossible to pass authenticating data in an URL parameter, and it seems that a framework that did do such a thing would be very hard to use for anything.

The capability-security community has known for a long time that separating designation and authority — for example, as in the paper, designating your private sales-leads mailbox with a name that anyone can guess and try to fool your browser into accessing with your authority on their behalf — leads to subtle security bugs. This is yet another example.

I’ve written a little bit about this in the past:
http://lists.canonical.org/pipermail/kragen-tol/2000-August/000619.html

Tyler Close’s “web-calculus” work is probably the closest thing we have to a generic solution to the problem: http://www.waterken.com/dev/Web/ — see also his “YURL” work at http://www.waterken.com/dev/YURL/

Jonas • April 2, 2007 5:58 PM

Only 4 comments and already there’s lots of wrong information…

  1. you don’t need to eval JSON, there’s also a more restrictive JSON-“parser” for JavaScript. They’re all available from json.org
  2. There’s also no need for a browser bug or DOM-access to exploit XSRF (Cross-site request forgery)-bugs. Browser’s loading script-tags behave exactly like they should.
  3. There already has been some discussion of this on the web lately. The security recommendations are pretty easy to follow:
    • don’t use data-changing GET requests
    • within your application, only publish public data at fixed URLs, use hard-to-guess URLs for private data
    • don’t “just eval()” JSON
    • don’t consume JSON by using dynamic script tags

for more go here:
“Safe JSON”
http://robubu.com/?p=24
and
JSON is not as safe as people think it is
http://getahead.org/blog/joe/2007/03/05/json_is_not_as_safe_as_people_think_it_is.html

XSRF-techniques were used to break Gmail over a year ago, so this is not exactly “new”

antibozo • April 2, 2007 6:17 PM

Jonas> you don’t need to eval JSON, there’s also a more restrictive JSON-“parser” for JavaScript.

Obviously one can parse JSON without evaling it. But JSON is designed for eval, and that’s why this problem exists. Any message format that could be parsed as JavaScript in the context of a SCRIPT element would have the same problem.

The issue I was raising is the mindset of the programmer who things an eval-based message architecture is a good idea. People who think that way write a lot of insecure code.

pdp • April 2, 2007 6:18 PM

@antibozo, @Josh,

I generalized a bit, however… what I am trying to say is that this paper does not outline anything new. This paper is all about how the developer can mess it up on the JSON side by exporting their results as either array or provide a callback. Yes, it is a problem. However, what bugs me is the actual exaggeration that was introduced.

Again, IMHO, this paper is more like marketing/PR campaign rather then actual security research because the vulnerabilities and issues are already disclosed and widely discussed in many blogs, mailing lists, etc.

The authors of the paper assume that every framework that supports JSON is directly vulnerable to the attack they describe but that is not true. Most AJAX applications use JSON but a lot of them use {} instead of [] and therefore are protected.

Moreover, the paper provides a protection mechanism that is flowed from top to bottom. I don’t want to get too much into JavaScript programming internals in this comment but the general truth is the following… if the attacker load code before yours and they properly overwrite the prototype of several objects thy can as well put the rest of the application in totally transparent sandbox, which means… no matter what kind of protection mechanisms you have there… they all will show a green light.

To sum up: I cannot see the purpose of this paper. I cannot understand why it is called JavaScript hijacking? JSON Hijacking is much better. I disagree completely that all the frameworks they mention are vulnerable. Again, if the framework exports results as [] or provide a callback without some sort of CSRF protection mechanism, then yes… this is a problem.

BTW, The while(1) loop technique was the trick that google used to block the contact list vulnerability discovered a couple of months ago.

Jim • April 2, 2007 7:54 PM

The authors of the paper assume that every framework that supports JSON is directly vulnerable to the attack they describe but that is not true. Most AJAX applications use JSON but a lot of them use {} instead of [] and therefore are protected.

Read it again, again. They aren’t protected.

Michael Koziarski • April 2, 2007 8:44 PM

This really does seem to be a special case of CSRF (aka XSRF) attacks. The solution would appear to be the same, use tokens in your URLs to prevent shenanigans.

It’s a clever use of javascript’s dynamic nature to aid with the capture, but if you can make the browser request private / dangerous URLs in another app, you can do a bunch of damage already.

Brian Chess • April 2, 2007 11:11 PM

Hi, I’m Brian Chess, I’m one of the authors of the paper. It’s been fun reading the discussion here. I think the paper does a decent job of addressing most of the issues being discussed, but I thought I’d directly comment on some of the statements I’ve read. Most of the things I might take issue with have already been corrected in subsequent posts, but I thought I’d try to collect everything together in one one place. If I get inspired, maybe I’ll turn this into a FAQ.

C: The System Administrators should be the ones concerned.

B: This is a software problem. It won’t be fixed until programmers fix it. The reason we’re talking about it is to try to raise awareness among the Ajax development community.

C: It doesn’t really look like an attack, just a method to parse the results of an already successful CSRF attack.

B: The Same Origin Policy implemented by all major web browsers is designed to prevent parsing the results of a CSRF attack. JavaScript Hijacking takes advantage of a hole in the Single Origin Policy. In many cases, allowing an attacker to both read and write data is significantly worse than simply allowing them to make illegitimate requests.

C: In order to get any of the examples running you need to have access to the page DOM via XSS or some sort of browser bug.

B: Not so. One of the most important things to note about JavaScript Hijacking is that it does not require the presence of another defect.

C: It’s actually not as bad as it could be, since very few people roll their own Ajax libraries.

B: The only data we could find on this subject suggest that 25% of Ajax programmers are rolling their own. Scary!

C: The paper does argue that any client-side framework requires your server to be vulnerable to this attack, but it is wrong.

B: The paper does not make that claim. Many of the client-side frameworks default to sending HTTP POST requests, which is a poor defense, but does not require the server to be vulnerable. We only characterize a framework as requiring a server to be vulnerable if it defaults to using HTTP GET and provides no defense against JavaScript Hijacking. When we first wrote the paper, none of the client side frameworks did anything to explain the problem to their users or to prevent a programmer from using the framework in a vulnerable way. We’re happy to see that that’s changing rapidly.

C: You don’t need to eval JSON, there’s also a more restrictive JSON-“parser” for JavaScript. They’re all available from json.org

B: The JSON parser from json.org eventually calls eval(), but it doesn’t really matter. Calling eval() is not a prerequisite to being vulnerable. All you have to do is create an object, so the problem exists no matter how you parse the JSON.

C: Most AJAX applications use JSON but a lot of them use {} instead of [] and therefore are protected.

B: This is entirely dependent upon the type of objects that the application is communicating. Array syntax is natural for communicating lists and other collections, and if the outermost structure is an array, all of the contents of the array are vulnerable. If the security of your program depends on your choice of data structures, you’re on thin ice.

C: what I am trying to say is that this paper does not outline anything new.

B: We did our best to give credit to relevant prior work, including Grossman’s Google attack and Joe Walker’s comments on JSON. What we think is new in the paper is:
1) The generalization of Grossman’s attack (he said it could not be used against JSON, but we show that it can).
2) An exploration of how widespread the problem is.
3) A discussion of the possible defenses against the attack.

pdp • April 3, 2007 2:10 AM

that’s cool Brian,

Thanks for clarifying.

I am still confused with the way the paper turns JSON a vulnerability. JSON is not perfect, for reasons you’ve mentioned, but it is not that bad. If properly used, JSON could be quite powerful and very fast because, in its most purest form, the code evaluates directly into the JavaScript interpreter. This way the developer does not need to care about parsing the data structure.

The only reason JSON Hijacking works is because by default the interpreter handles anonymous Arrays which I don’t think that have any purpose at all. Maybe I am wrong.

So yes [‘John’, ‘Fred’] evaluates properly and can be hijacked via CSRF but {names:[‘John’, ‘Fred’]} will trigger an error.

Why don’t u call the paper JSON Hijacking. JavaScript hijacking is too vague and usually refers to a technique that describes how to create a sandbox around the application for monitoring purposes.

antibozo • April 3, 2007 8:59 AM

pdp> If properly used, JSON could be quite powerful and very fast because, in its most purest form, the code evaluates directly into the JavaScript interpreter.

Gods, help us.

That is exactly why it shouldn’t be used. There are plenty of efficient ways to serialize data structures that don’t render them confusable with code. That people are deliberately using a dangerous serialization strategy for perceived benefits in speed is clear evidence that general knowledge of security is not improving. This is especially true in this context–a slow, interpreted language makes a remote procedure call, and people are so keen to shave a couple of milliseconds off the result parsing time they are willing to navigate a security minefield? And has anyone even demonstrated that the JavaScript parser is actually faster than the alternatives?

No, I suspect the JSON design wasn’t chosen for speed anyway–it was because someone was both too lazy to write a parser and forgot what the X in AJAX stands for. What’s scary is how many other clowns hopped on board that rattle-trap streetcar.

Gods, help us.

Dale Newfield • April 3, 2007 11:05 AM

I don’t believe the “Preventing Direct Execution of the Response” suggestions in this paper are sufficient. eval is just another function, which can be redefined. Wouldn’t this break the gmail “solution” mentioned?

  var orig_eval = eval;
  eval = function(arg) {
    if (arg && arg.substr(0,9) == "while(1);") {
      arg = arg.substring(9);
    }
    return orig_eval(arg);
  }

Dale Newfield • April 3, 2007 11:42 AM

Or, eliminating the need for the global var:
eval = function(orig_eval) {
  return function(arg) {
    if (arg && arg.substr(0,9) == “while(1);”) {
      arg = arg.substring(9);
    }
    return orig_eval(arg);
  }
}(eval);

antibozo • April 3, 2007 12:13 PM

The preventive suggestions are not intended to break eval; they are intended to keep the result document from being successfully evaluated as JavaScript in the context of a SCRIPT element.

Andrew Dupont • April 3, 2007 3:03 PM

I can confirm that this is a new thing — not just a restating of a previous XSS or XSRF flaw — but I think it has greater implications for API architects than for JavaScript library authors.

Consider the following:
(1) Bob’s web site is all Ajaxified and uses a RESTful JSON API to serve data to the client.
(2) Alice logs into Bob’s web site and has a session token set via cookie.
(3) Alice then visits Carol’s web site. Carol dynamically appends a SCRIPT tag with the SRC attribute set to a URL on Bob’s site. Since Alice is logged into Bob’s site, Bob assumes the requester can be trusted with Alice’s sensitive data.

Since Carol can’t read the JSON response in as a string, she has to hook into the JS interpreter herself by overriding a constructor for a native datatype (like Array or Object).

So it seems to me that this problem is most easily fixed on Bob’s end: he should check the referrer or use some sort of shared secret to ensure that the only responses that contain sensitive information are those that Bob himself knows about.

Or he can do what Brian’s paper suggests: surround the JSON response in comment delimiters, so that it can be evaluated only by those who can examine the response text (i.e., not Carol). We on the Prototype core team have discussed implementing something like this in an upcoming version.

Tim Harris • April 3, 2007 4:23 PM

My simple solution… DO NOT USE AJAX !!!

To the people that DO use it, you will make me happy with much business as hackers begin to attack just AJAX applications. Yet another overhyped product to roll out of silicon valley I presume. You smart people just give us Texans way too much to look forward to !!!

Daniel Haran • April 3, 2007 4:54 PM

@Andrew: Glad to see you guys are addressing this. The comment delimiters seem hackish – checking the referrer and using a shared secret seem sufficient. If a person is clever enough to try this type of attack, chances are they can remove whatever comment delimiters you throw at them.

Tobie Langel • April 4, 2007 12:14 AM

@ Daniel: Since the attacker’s only option is to use a dynamic script to grab the data (thanks to the SOP), commenting the data out is a sufficient protection, as there is no way to access it if it’s in a script tag (nor to strip the comments).

Matt Kruse • April 4, 2007 11:03 AM

The sky is not falling. JSON is not a problem. Ajax is not a problem. The JS frameworks are not a problem.

As far as I can tell, web site authors should only care about this if:
1. You serve JSON from GET requests
2. The JSON is an array [], not an object {}
3. The data contains private information
4. The only authentication done is checking that a session exists.

From my experience, very, very few sites would ever meet all of these conditions.

I would love to see a single real-world example that exists right now that is vulnerable to this attack.

antibozo • April 4, 2007 11:11 AM

I have to agree with pdp that calling this “AJAX hacking” or “JavaScript hacking” is total nonsense. The problem is clearly with JSON, and this only implicates AJAX to the extent that fools use JSON in a broken fashion–and it shouldn’t even properly be called AJAX in that case. Now these web application scanner vendors are abusing the situation to sell more of their ineffectual products through hype and hysteria.

antibozo • April 4, 2007 11:15 AM

Matt Kruse> As far as I can tell, web site authors should only care about this if:
Matt Kruse> 2. The JSON is an array [], not an object {}

Yeah, and you think building a house on that semantic precipice is a good idea?

Matt Kruse • April 4, 2007 11:23 AM

@antibozo: The point is, that’s just one condition that must be met for this to even be an exploit. I deliver array’s via JSON without fear in some places because I don’t meet the other conditions.

Yes, it’s a potential problem. Sure, it should be addressed.

My point is, this is NOT a big concern for anyone I know of because I can’t find a single site that could be exploited in this manner. Until someone exploits this in a way that could impact more than 3 people (say, for example, grab meaningful paypal data), it’s just an interesting quirk with very little real-world impact. It does NOT deserve to be posted to a thousand blogs and news sites and inciting panic as seems to be the case now.

It’s propaganda. Kudos to Fortify for a brilliant advertising campaign.

antibozo • April 4, 2007 11:37 AM

Matt Kruse> The point is, that’s just one condition that must be met for this to even be an exploit.

How certain are you of that?

And do you really expect people to disclose vulnerable sites here?

I agree that propaganda is involved, on both sides.

Brian Chess • April 4, 2007 12:58 PM

pdp> I am still confused with the way the paper turns JSON a vulnerability.

You’re right that the problem is not restricted to JSON. Actually, that’s why we named the problem JavaScript Hijacking; it affects any system that uses JavaScript as a data transport format. I’ve seen other formats–some that are much more vulnerable than JSON. (A list of function calls where the data is in each function call’s parameter list, for example.) The reason we focused on JSON in the paper is that it seems to be the most popular format in widespread use.

Arrays are important in JSON. If you’d like to communicate a list of email messages, a set of bank accounts, or any other collection, an array is the natural way to do it. You certainly could protect yourself from JavaScript Hijacking by making sure that you only return objects and never arrays, but now you’ve got to think about JavaScript Hijacking every time you write a new method. Better to build some protections into the transport code.

There’s been a lot of interesting work on JavaScript going on in the exploit development world lately. People have really woken up to the fact that JavaScript is a powerful exploit writing tool. The CCC paper mentioned earlier is a great example of that kind of work. However, the CCC paper begins with the assumption that the web application contains a defect such as a cross-site scripting vulnerability that allows an attacker to inject malicious code. The reason why the JavaScript Hijacking technique needs its own name is that it does not require any cross-site scripting, response splitting, or other well-understood type of vulnerability to be present. It is a different animal.

As to the question of whether or not programmers should be moving data around with JavaScript, I don’t have any useful answer. The fact is that programmers are doing it, and all indications are they’re going to do more of it. For the most part they’re doing it without any idea about the security risks involved. That’s what I want to change and why I think it’s important to bring attention to new attacks like JavaScript Hijacking.

In his original post, Bruce doesn’t sound like he’s very hopeful that programmers will adopt reasonable secure coding techniques. I think I’m a little more hopeful than he is, but what I can say for sure is that, if there’s any chance that programmers can do a better job of getting security right, we security folks need to explain the risks as best we can.

antibozo • April 4, 2007 1:24 PM

Brian Chess> it affects any system that uses JavaScript as a data transport format.

Fair enough. But that’s not even remotely what the term “JavaScript Hijacking” suggests. And unfortunately, a lot of people are generalizing even beyond that and characterizing AJAX in this light, which is is inaccurate because “AJAX” uses XML as its message format, not JavaScript. Blood over the dam now, and the paper seems like good work to me, but more thought should have gone into your terminology.

Matt Kruse • April 4, 2007 2:14 PM

Okay, I’ve officially hit the first instance of “I just read that Ajax has security problems, maybe we should do something else” since this was released.

This is the real impact of propaganda scare-tactic “news releases” like this. In the real world this paper probably won’t protect anyone (still haven’t heard of a single real exploit, even from the hacker community) but rather it will cause well-intentioned but uninformed people to form a bias against ajax and further the existing biases against javascript.

What a shame.

FooDoo • April 4, 2007 4:20 PM

It should be interesting to see what is possible now that Jitko has been leaked.

RG3 • April 5, 2007 2:50 PM

“programmers don’t understand the security implications of their work”

I consider myself security-aware. Possibly more than most programmers. But I tried my hand at one of the sample tests at http://www.sans-ssi.org/ at got 3/10 on my first go.

I think the problem is largely one of training – when people are trained in the dark art of programming, security is considered an “add-on”, rather than something that should pervade the whole process.

kentaromiura • April 8, 2007 4:20 AM

@Andrew:
I don’t think so.

if an attacker can execute javascript surrounding with comment or poisoning the data with garbage is not a good solution, if you can strip out comment, so the attacker can.

In Js there is no secret, all the code is readable and then a shared secret(like webservice) is pretty much shared and not more secret.

and i think that using post instead of get don’t prevent nothing.

me and andrea giammarchi
[http://webreflection.blogspot.com/]
had a brainstorming, but in the end our result was that is always possible to an attacker to get the data.
i’m working on the last try, trying to get a case where if the attacker try to redefine something he get in a circular reference, but even if i solve this (allowing a safe eval) not all problems are solved.
Bye 😉

antibozo • April 8, 2007 11:00 AM

kentaromiura> if an attacker can execute javascript surrounding with comment or poisoning the data with garbage is not a good solution, if you can strip out comment, so the attacker can.

An attacker has no opportunity to modify the content returned to the browser when it evaluates a SCRIPT tag before it is passed to the JavaScript interpreter, nor can he modify the request method (always GET). That is the scenario under discussion. Go back and read the paper again.

kentaromiura • April 8, 2007 5:09 PM

I don’t need to.
as I already said if an attacker could execute javascript it can totally rewrite your page, or a smarter one could add an iframe to allow cross domain xmlhttprequest, that for the sake can use post ^_^;;
so get or post make no difference.

as I just said if an attacker can execute code, it don’t need to eval nothing, the goal of the attacker is to stole information, so it can make a fake xmlhttprequest(or use a fake object or function) and use the iframe to save your data, actually he can NEVER eval your code, but he have stole it.

so poison the data don’t automatically protect you. neither use get or post.

neither my solution, because if an attacker add a script at the very end of the page(and use for example dean edward ondomcontentloaded) and delete what i just rewrote then he make my efford null.

the solution is to don’t send the data.

antibozo • April 9, 2007 1:14 PM

kentarmiura> can make a fake xmlhttprequest(or use a fake object or function) and use the iframe to save your data

Actually, he can’t. That’s what the so-called “Same Origin Policy” prevents. The described attack exploits a loophole in this policy, namely that JavaScript imported to a page via the SCRIPT element does not have to come from the same server as the enclosing document. Documents retrieved via an XmlHttpRequest object or IFRAME, on the other hand, are not accessible to a requester with a different origin than the requested document.

Like I say, go back and read the paper again.

kn • April 9, 2007 4:47 PM

Is there any real world application out in the wild that is vulnerable to javascript hijacking ?

seems like this issue is not very prevalent.

antibozo • April 9, 2007 5:18 PM

kentaromiura> yes, so this http://dojotoolkit.org/node/87 is only bullshit.

That IFRAMEs can coordinate deliberately with a parent document in order to exchange messages via URL fragment identifiers does not mean that an attacker can spy at will on a document in an IFRAME from another server. If such spying were possible, the whole fragment id hack wouldn’t be necessary. A service built using that strategy could conceivably have vulnerabilities similar to the one described here, however.

Do yourself a favor and try implementing the attack you described. It will better acquaint you with the limitations imposed on JavaScript.

TK • April 10, 2007 8:39 AM

antibozo> No, I suspect the JSON design wasn’t chosen for speed anyway–it was because someone was both too lazy to write a parser and forgot what the X in AJAX stands for. (…) And unfortunately, a lot of people are generalizing even beyond that and characterizing AJAX in this light, which is is inaccurate because “AJAX” uses XML as its message format, not JavaScript.

The X in AJAX doesn’t really stand for XML as a data transfer format but more for XHTML (including the DOM capabilities to change the HTML on the fly) and the XmlHttpRequest object.

Quoted from http://www.adaptivepath.com/publications/essays/archives/000385.php :

“… Ajax incorporates:

* standards-based presentation using XHTML and CSS;
* dynamic display and interaction using the Document Object Model;
* data interchange and manipulation using XML and XSLT;
* asynchronous data retrieval using XMLHttpRequest;
* and JavaScript binding everything together."

Although it mentions XML as the data interchange format, there are these questions in the FAQ, on the same site:

“Q. Why did you feel the need to give this a name?

A. I needed something shorter than “Asynchronous JavaScript+CSS+DOM+XMLHttpRequest??? to use when discussing this approach with clients.

(…)

Q. Some of the Google examples you cite don’t use XML at all. Do I have to use XML and/or XSLT in an Ajax application?

A. No. XML is the most fully-developed means of getting data in and out of an Ajax client, but there’s no reason you couldn’t accomplish the same effects using a technology like JavaScript Object Notation or any similar means of structuring data for interchange.”

Lastly, from Wikipedia:

“XML is sometimes used as the format for transferring data between the server and client, although any format will work, including preformatted HTML, plain text, JSON and even EBML. These files may be created dynamically by some form of server-side scripting.”

A brazilian news site published the following (translated to English):

“According to Fortify, the source of the problem is that the AJAX applications are setting aside the X (of XML). This way, the application does everything in Javascript and therefore is unsafe.”

That was what worried me most, so I felt like clearing it up. Plus any good Ajax application should never do “everything in Javascript.”

About the paper itself, although some may say it doesn’t mention anything new, it’s useful as for putting together most of the security concerns developers should be aware of when working with ‘Javascript code’ as a data transfer format.

antibozo • April 10, 2007 9:27 AM

TK, yes, I’m aware that the original meaning of the X (it did stand for XML when the term was first promulgated) has been lost in what is now typically called “AJAX”. I simply think it’s indicative of the ignorance of a lot “AJAX” “programmers” that they are unaware of the meaning of the acronym. It’s just a little illustrative side issue to the real flaws of the JSON approach–that it encourages using eval on externally supplied data that is typically too complex to use regular expressions to sanity-check, and that APIs that use JSON or any JavaScript notation as a message format are far less compatible with languages other than JavaScript, so if you want to build another program in Java or Perl that calls into the same API, you have to find some ugly JavaScript parser to extricate the data. Hell, even Microsoft’s VIEWSTATE syntax would be more compact and interoperable for most applications than JSON, if for some reason XML is not an option.

I agree on the paper itself; it’s useful to shine a light on any class of vulnerabilities that may result from an increasingly common architecture. The only issue I take with the paper is the absurdly broad-brush approach of calling it “JavaScript Hijacking”.

antibozo • April 13, 2007 5:07 PM

kentaromiura> http://yuiblog.com/blog/2007/04/10/json-and-browser-security/

If you’re referring to the section entitled “Script Tags”, what the author describes is the reverse of the attack the “JavaScript Hijacking” paper is about.

In the paper, the victim visits an outer page authored by an attacker, which includes a SCRIPT element pointing to an AJAX service that delivers some form of JavaScript-encoded message, and the outer page then captures the message by overriding object instantiation methods. This does not require any cross-site scripting vulnerability in the AJAX application; all it requires is for the victim to visit the attacker’s page, and for the AJAX application to encode messages in a vulnerable JavaScript format.

The closest to this attack the URL you cite comes to is this:

“Another use of script tags is to deliver JSON data from different sites. There is absolutely no protection against the case where the different site sends dangerous scripts instead of benign JSON data.”

This is the reverse scenario; in this case, the outer document is trusted and it uses a SCRIPT to include an inner, malicious document. This has always been known to be a vulnerable design because the script included via SCRIPT has access to the DOM of the outer document.

But in “JavaScript Hijacking”, the outer document is malicious, and uses a SCRIPT to include an inner, trusted document. This is a completely different animal because the outer document is not supposed to have access to the DOM of any inner document that originates from a different server.

I think you still don’t understand the vulnerability and that we are talking at cross purposes. I look forward to reading your article, though. I will keep checking back here.

antibozo • April 13, 2007 5:21 PM

kentaromiura> http://yuiblog.com/blog/2007/04/10/json-and-browser-security/

That document also says this:

“Since script tags are exempt from the Same Origin Policy, a script tag can be used from any page to make a GET request of your server. The request will even include your cookies. If the response contains confidential information, then your server must refuse the request.

“There are people who are selling magic wrappers to put around JSON text to prevent delivery to unauthorized receivers. Avoid that stuff. It will fail when new browser bugs are created and discovered, and in some cases might introduce painful new exploits.”

Here’s better advice: stop encoding messages as script. No, doing so is not a vulnerability in itself, but it trains people to write vulnerable code.

kentaromiura • April 14, 2007 2:16 PM

@antibozo:
you are right, the paper describe the reverse scenario.

I was speaking about when someone put a script in your page (either by make you click on a link or using some bug in a webpage)
In this case the attacker could do what he want.

In Fortify scenario, the attacker could use a proxy for make a post instead of a get and return the data cleaned [stripping out the comments and the while(1);].

So the defensor must check server side that the page that make the request come from the same domain.
thank you for clearing out this to me, now I must rewrite my article adding this case.

antibozo • April 14, 2007 2:52 PM

kentaromiura> In Fortify scenario, the attacker could use a proxy for make a post instead of a get and return the data cleaned [stripping out the comments and the while(1);].

If the attacker points the SCRIPT at a proxy, the browser won’t send the cookie or HTTP authentication info, so from the AJAX service’s perspective, the proxy will be like any other anonymous client. The browser will only send authenticators directly to the AJAX service.

kentaromiura • April 14, 2007 3:36 PM

seems that is not possible to execute cross-domain data leakage attack using Flash because of its crossdomain.xml security model because the server would have to explicitly allow it,well i’m a bit reassured

Ti • April 16, 2007 12:56 PM

@kentaromiura: it’s a good thing you didn’t write that crap of a paper, the last thing we need is more false claims about how vulnerable Javascript is. you should thank antibozo for educating you on the basics

antibozo • April 16, 2007 1:40 PM

Ti, though I appreciate the vote of confidence, your comment is pretty harsh; I chalk this up to English’s not being kentaromiura’s first language, and he did cite some interesting links, so no harm, no foul.

kentaromiura • April 17, 2007 11:16 AM

@Ti:Sorry for my misurestanding, but actually I think that javascript is pretty vulnerable, expecially when someone don’t take care of the server side, as i already said if one attacker can execute even few bytes of javascript,due to a bug in the application, it can totally rewrite all the code in your application and you can’t do nothing to prevent it.

@antibozo:Ti is right, I have to thank you, I don’t public my paper because out there there is lot of code injection article.
Since i put lot of efford in it these days I still thinking on rewrite it better,focusing on other interesting things I found..

Mike Koss • April 22, 2007 11:59 AM

It seems to me, the popularity of using <SCRIPT>-includes, derives from the desire to be able to implement client-side mashups (which must be able to get around the same-source cross-site scripting protections of the browser). Web services that want to support these are bundling their data access API’s inside of <SCRIPT>-includes. So, if these calls can return private user data, the script will necessarily co-mingle it’s objects with those of the outer (potentially malicious) page.

I think what this paper highlights is that there is no such thing as a “safe” <SCRIPT>-based mashup returning private data. Unless the calling page can pass some hard-to-guess and time-limited identifier in the <SCRIPT> request, there are many techniques for the outer page to sniff out the data objects created by the inner <SCRIPT>.

antibozo • April 22, 2007 1:41 PM

Mike Koss> I think what this paper highlights is that there is no such thing as a “safe” -based mashup returning private data.

I think you’re not quite getting it. Yes, any page that uses SCRIPT to include a document from a server under someone else’s control is potentially dangerous. That’s not what this attack is about. In this attack, the system being exploited might not use a mashup at all, and whether it does is irrelevant. The attacker is the one using a mashup, deliberately.

Mike Koss> Unless the calling page can pass some hard-to-guess and time-limited identifier in the request, there are many techniques for the outer page to sniff out the data objects created by the inner .

No, there aren’t. But there is at least one, which is the technique described in the paper. That technique recovers messages encoded as JavaScript in certain cases, and it doesn’t matter whether the “calling page” passes an additional authenticator; the difference should be that the service, if coded securely, would refrain from transmitting private data if the caller is authenticated only by a cookie-based session id.

I think you need to read the paper once more, and review the so-called “same origin policy”.

Mike Koss • April 23, 2007 11:29 AM

antibozo: The point I was trying to make is that the popularity of using a cross-site <SCRIPT> tag is due to people creating “mashups”. If all your functionality is available on a single server, there is not a compelling reason to implement your data interfaces via <SCRIPT> tags, but rather most sites should be using XMLHttpRequest – where browsers enforce Same Source rules.

So, what I get from this paper is – unless you’re explicitly designing your interface to support a mashup – you shouldn’t be using the <SCRIPT> tag as a data transport.

As to my last point about “many techniques” available to access the objects that come from a <SCRIPT>, I realize that the paper describes one – trapping the setter event on an Object class member. My claim is that there are actually many more holes than this – just addressing the one described, does not necessarily solve the root problem. I believe all the objects created inside the <SCRIPT> tag are available in the same name-space as the containing page; so there are other techniques available to get access to global variables, etc. depending on what the malicious page knows about the specifics of the behavior of the target <SCRIPT>.

antibozo • April 23, 2007 12:40 PM

Mike Koss> So, what I get from this paper is – unless you’re explicitly designing your interface to support a mashup – you shouldn’t be using the tag as a data transport.

Again, the vulnerable service doesn’t use SCRIPT as a vehicle for message transport. No one does, except the attacker.

Mike Koss> My claim is that there are actually many more holes than this – just addressing the one described, does not necessarily solve the root problem.

That may be true, and that’s one of the several reasons not to use JavaScript as a message transport (as JSON does).

Mike Koss> I believe all the objects created inside the tag are available in the same name-space as the containing page; so there are other techniques available to get access to global variables, etc. depending on what the malicious page knows about the specifics of the behavior of the target .

The type of message transport under attack doesn’t set any global variables*. It presents a JavaScript initializer, which a legitimate client could turn into a local object by passing it to eval(). For example, a legitimate client might use an XmlHttpRequest object to request a document from the service, and the service might send back: “very secret value encoded as a JavaScript string\n”. The client could then turn this into a local object by doing “var secretValue = eval (resultDoc);”. No SCRIPT is involved. The legitimate client is allowed to pass resultDoc to eval because resultDoc came from the same origin as the client.

The attacker doesn’t have the same access to result documents from the service, because the malicious page has a different origin. So the attacker instead uses SCRIPT to request the secret document because SCRIPT isn’t subject to the “same origin policy”. This still isn’t adequate for the attacker because the attacker can’t directly read the result document–bare initializers don’t have side effects*. But munging of the JavaScript interpreter allows interception of the message as it is being parsed.

The feasability of this attack is a side effect of the choice by the service’s author to use JavaScript as its message transport, because he is too lazy or ignorant either to write a parser for his messages encoded in a sane format, or to simply use XML for messages and handle results using the native JavaScript DOM API.

No offense, but please go back and read the paper again.

  • If the vulnerable service does set global variables or use messages that call predefined functions, attacking it is easier and doesn’t require fooling with the JavaScript interpreter. The paper describes attacks against services that use bare initializers as messages.

geciktirici • July 15, 2008 8:49 AM

The attacker doesn’t have the same access to result documents from the service, because the malicious page has a different origin. So the attacker instead uses SCRIPT to request the secret document because SCRIPT isn’t subject to the “same origin policy”. This still isn’t adequate for the attacker because the attacker can’t directly read the result document–bare initializers don’t have side effects*. But munging of the JavaScript interpreter allows interception of the message as it is being parsed

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.