Updated
I just got an email from Joe Hart over at SecureTest with a screen shoot confirming IE6 + XP SP2 + Acrobat Reader 6 is vulnerable.

Now we have:
IE6 + Acrobat Reader 4 + XP SP2
IE6 + Acrobat Reader 6 + XP SP2
IE6 + Acrobat Reader 7 + XP SP1
(possibly) IE 6 on non-XP platforms
Firefox 2.0.0.1
Firefox 1.5.0.8
Opera 8.5.4 build 770
Opera 9.10.8679

RSnake is a fucking genius. Using a file:/// URL pointed at the manual PDF installed with Acrobat, you can execute JavaScript in the local zone. Oh yeah, local file access, program execution, completely uncrippled XmlHttpRequest.

This is not good.

It hits the fan!

There is a flaw in Abode’s Acrobat reader plugin which allows JavaScript to execute. This flaws means ever website that contains a PDF file has a de facto Cross Site Scripting (XSS) vulnerability. Clicking on a link like http://bank.com/report.pdf#EVILCode will cause JavaScript to execute in the context of bank.com. Regardless of how security bank.com’s website is, attackers can get their own JavaScript to interact with the website, exposing everyone on bank.com to all the traditional dangers of XSS. It is important to note that there is nothing wrong or malicious about the PDF file itself. An attack doesn’t need to upload a malicious file for this to work. The issue is Adobe executes an JavaScript that is contained in the fragment (#) of a hyperlink.

This flaw essentially backdoors every website on the Internet that hosts a PDF. Any website with a PDF can be the target of a hyperlink with a malicious fragment added to it. This flaw is so extremely dangerous because an attacker simply creates a malicious hyperlink to any legitimate PDF on any website and can attack that website.

It gets worse, because there is little a website can do to stop the attack. If a victim clicks on a link like http://bank.com/report.pdf#EVILCode, the #EVILCode fragment is not actually sent to bank.com. Thus bank.com cannot detect if a PDF is being requested to launch an attack, or is being requested for legitimate purposes Short of removing all PDF’s from their site, a company cannot protect itself or it’s users from this technique. This flaw can also be exploited using an HTML iFrame. This means a victim doesn’t have to physically click on a bad link; simply viewing a website could cause a PDF to load and exploit the user.

XSS can be used for various types of attacks, such as phishing, password stealing, self-propagating worms, keystroke logging, and attacking internal corporate networks.

This vulnerability is interesting because it occurs in a browser plugin, making all browser’s that use the plugin vulnerable. It is also interesting because it doesn’t require an attacker to create or upload a malicious file. This attack piggybacks on top of perfectly safe PDFs.

Updated
Effected Browser: (all on Windows)
IE6 + Acrobat Reader 7 + XP SP1
IE6 + Acrobat Reader 4 + XP SP2
(possibly) IE 6 on non-XP platforms
Firefox 2.0.0.1
Firefox 1.5.0.8
Opera 8.5.4 build 770
Opera 9.10.8679

Jello wrote:

Acidus wrote:

new Ajax.Request('?url=backend',{onSuccess:responseHandler});
var responseHandler = function(t) { json = eval(t.getResponseHeader('X-JSON'));

eval() is the WORST thing you can ever do in JavaScript and people who process JSON with eval() should be punched in the face.

Quoting from the great Douglas Crockford:

However, [eval()] can compile and execute any JavaScript program, so there can be security issues. The use of eval is indicated when the source is trusted. This is commonly the case in web applications when a web server is providing both the base page and the JSON data. There are cases where the source is not trusted. In particular, clients should never be trusted.

When security is a concern it is better to use a JSON parser. A JSON parser will only recognize JSON text and so is much safer:

var jsonObject = eval('(' + jsonString + ')');

You mean like that?

Ducks.

As Crockford (the man who invented JSON) states, eval give access to the full JavaScript compiler. Using eval to parse JSON can be attacked 2 ways:

1- You have a mashup or data from other sources that you cannot trust.
2- Unvalidated user input is placed inside the object being returned by JSON.

Consider receiving/processing a JSON object which is an Array of someone name.

["Alice", "Eve", "Bob"]

Eve makes her name ""]; alert('xss');//
Now what gets evaled is ["Alice", ""];alert('xss');//", "Bob"]

Eve has achieved code execution!

Once again something that an be solved if all user input is properly validated, included data from 3rd party sites.

However, the big reason I made this most is that Prototype (and thus Script.aculo.us) has a built in feature, to always eval the contents of an HTTP header! I doubt most people using the framework know this exists, and short of modifying the framework, it doesn't appear that you can turn it off.

At what point does a feature become a backdoor?

More on: X-JSON in Prototype

new Ajax.Request('?url=backend',{onSuccess:responseHandler});
var responseHandler = function(t) { json = eval(t.getResponseHeader('X-JSON'));

eval() is the WORST thing you can ever do in JavaScript and people who process JSON with eval() should be punched in the face.

Quoting from the great Douglas Crockford:

However, [eval()] can compile and execute any JavaScript program, so there can be security issues. The use of eval is indicated when the source is trusted. This is commonly the case in web applications when a web server is providing both the base page and the JSON data. There are cases where the source is not trusted. In particular, clients should never be trusted.

When security is a concern it is better to use a JSON parser. A JSON parser will only recognize JSON text and so is much safer:

X-JSON in Prototype

January 2007
Cover Story

Stronger Security: How to Clean Up Your AJAX Applications. Apps built with AJAX offer more options than their page-based counterparts -- along with a higher risk of vulnerabilities. Here's how to keep your apps squeaky clean. By Billy Hoffman and Bryan Sullivan

My co-author Bryan Sullivan and I wrote the cover story on January's Software Test and Performance magazine. Editor's on our side and their side trimmed some of the more technical details, but I'm very happy with the results.

You can download the issue in PDF.

Ajax cover story in Software Test and Performance magazine

It seems more and more of my sentences recently start "Fucking IE wouldn't do _______."

I spent last night re-working the 3 Memestreams recommendation bookmarklets into a single bookmarklet. It's a little clumsy to have 3, they don't all do the same thing or present the same UI, and there's a bug when selecting text inside of a frame. So I get going and quickly create a better one. Problems with IE quickly develop:

1- You cannot drag "javascript:" bookmarks onto the toolbar if you have IE6+XPSP2 for security reasons. Ok, I'm on broad so far, but a prompt would have been nice instead of a flat denial. To be able to drag bookmarklets, you have to add the site to the list of trusted sites! This is a huge jump in what a site can and cannot do and a good example of how Microsoft is too coarse with their security settings. There should be a prompt to temporarily add a bookmarklet. I should not have to drastically and permanently elevate a site's trust to do this.

2- IE's JavaScript debugger sucks big time. Even the advanced version. Oh my kingdom for full blown Firebug in IE.

3- IE limits the size of a "javascript:" link to 508 characters! This makes having advanced bookmarklets for IE very annoying. Instead the bookmarklet has to bootstrap a larger JavaScript file by dynamically creating a <SCRIPT SRC="http://site.com/more.js">. But this is actually a privacy violation, because the HTTP request for the larger JavaScript file will have a referer (sic) header with the webpage the person is invoking the bookmarklet on! For Memestreams that's not as big of a problem, because you were about to tell Memestreams what URL you were looking at anyway. However there are many other types of bookmarklets where this could be very bad.

Now to be fair, fucking Firefox! It allows you to have multiple pieces of text selected on a page at the same time. For example, I could have text selected in the regaulr page, in multiple textboxes and text fields, and in multiple frames and iframes. From a bookmarklet point of view this makes it tough to know what text the user really cares about. The existing bookmarklet concatenates all the text together which is probably not what most people want.

In preparing a report, someone asked me how Ajax affects Denial of Service attacks. As I said in this post XmlHttpRequest doesn't really change things, because JavaScript could already generate HTTP traffic. In fact, XmlHttpRequest (the workhorse of Ajax) can only talk to the domain it comes from. Thus, I could make a botnet of MySpace users using an XSS vuln, but with XmlHttpRequest I could only attack MySpace with it.

So yet another way for JavaScript to generate HTTP traffic doesn't really change things. Is there anything else about Ajax that could affect DoS attacks?

I think so.

I would argue the way Ajax applications can make you more open to a DoS is from all the open web services and Ajax endpoints. A flood of traffic to an Ajax endpoint is worse than a traffic flood against a random wenpage because each time you contact that webservice the server has some computation to do. Presumably moreso than the computation to simply serve a webpage. Furthermore, responses from Ajax endpoints are not typically cached by a Squid proxy or any other “website accelerator” the way web pages are. Even if they were, this wouldn't help very much. Think about how often someone requests the login webpage versus someone contacting a webservice to spell check Aardvark.

Another DoS vector I see with Ajax applications is something I'm going to call Control Logic Denial of Service. All those web services and Ajax endpoints are API calls into the application. By looking at the JavaScript code that’s pushed to the client, I can see in what order and how often these webservices are contacted, as well as what the parameters are. In essence, this is a blueprint of the steps the applications takes to function normally. However, it is also a blueprint on how to use the application incorrectly. Some webservice may allocated resources where as another one cleans it up. An attacker could simply never call the clean up functions. Or I simply call all the functions out of order. Even if the code fails gracefully, it is extremely expensive for a program to generate an Exception, even it gets caught.

A traffic flooding DoS is like throws millions of small punches hoping you take an opponent down. A Control Logic DoS is like cutting open their head and punching them a few times in the brain.

Now, before Memestreams gets a bunch of web sec people registering to bitch at me that this isn't new, you are right. I'm sure this has been done before in various situations. Could you do this attack against a web app before Ajax? Probably. If I have a three step registration process spread over three webpages, calling them out of order could have the same effect. One difference I see is that in this situtation, the only way I could know the control flow (i.e., PageA POSTs to PageB which POSTs to PageX) would be to actually walk through the web app myself. In contrast, Ajax applications typically expose their entire API in a single webpage with a mass of JavaScript which would contain the callback code. This happens more than you would think. See Alex Stamos's Blackhat presentation for more details on how Ajax apps expose their entire API.

Method binding

As a consequence of this being "passed" to functions, this is not fixed for a function. That means that a function does not have an "owner" or "parent", even if it is a method. In other words, a method is not bound to the object that it is a method of.

A more general explanation of the underline problem of my last post. Essentially, what object the keyword this references inside of a function can change, based "who" is calling the function.

    //constructor for new Car object
    function Car(name) {
        this.name = name;
    }
    //method for object
    function Car_display() {
        alert(this.name);
    }
    //adds the method display() to all car objects
    Car.prototype.display = Car_display;

    //creates a new Car object
    var car = new Car("Vette");

    car.display(); //prints out "Vette" as expected

    //creates a new Car object
    var car2 = new Car("Truck");

    car2.display(); //prints out "Truck" as expected


    //grab a reference to the car function
    var carfunc = car.display;
    //set a global variable whose name is name
    var name = "HAHAHA!";
    
    carfunc();     //prints out "HAHAHA"  WTF?
    Car_display(); //prints out "HAHAHA"  WTF?

Here is what's happening. When JavaScript executes the state car.display() it first finds the function pointed to by the variable car.display; That function is Car_display. JavaScript also sets the this variable to the object which called the function. In this case, that object was car which we created. Thus Car_display is executed and the this variable points to the object car which contains a member variable name.

What about car2.display()? The same thing. JavaScript it first finds the function pointed to by the variable car2.display; That function is still Car_display. JavaScript also sets the this variable to the object which called the function. In this case, that object was car2. Thus Car_display is executed and this is pointing to the car2 variable, whose name variable is "Truck."

There is a single function Car_display, and all instances of a car object simply call that function, and JavaScript sets up the "environment" so that is it accessing the proper variables.

Nothing so far is too different than a OO language like C# or Java.

Next we save a reference to the function car.display, which is really a reference to Car_display, in the variable carfunc When we execute the statement carfunc() are calling the function Car_display. But what is the value of this? Well, since the function was called in the global context, this references to the global object. All function and variables in the program are ultimately part of the global object. In this example the global object has the following variables:

-Car: a function
-Car_display: a function
-car: a variable, currently an instance of a Car object
-car2: a variable, currently an instance of a Car object
-carfunc: a variable which references the function Car_display
-name: a variable, currently set to the string "HAHAHA"

So, carfunc() calls the function Car_display, and sets the variable this to point at the global object. Since this.name reference to the global object's variable name, the function displays "HAHAHA."

A closure allows you to get around this weirdness. See the referenced article for more information

Its all relative: When 'this' doesn't actually refer to 'this'

Or, solving the scope issue of callback functions without resorting to global variables!

//set the var so we can scope the callback var _this = this;
//callback will be an anonymous function that calls back into our class
//this allows the call back in which we handle the response (_onData())
// to have the correct scope.
this._request.onreadystatechange = function(){_this._onData()};

Encapsulating XmlHttpRequest Calls within JavaScript classes