Publishing on the Web is very different from older methods of publication. A Web publication is inherently a general, device-independent and program-independent document with structural markup. The presentation of a document may vary greatly, and it must vary, to allow viewing (or hearing) the same document on a wide variety of devices, ranging from wristwatch monitors to full-size movie screens.

Why the fuck don't we get this yet? We've been doing this for 17 years now, and for all the trendy lip service arty web geeks pay to upholding "web standards" we still end up with shit like this. Got a large screen? Too bad. Fixed margins. Pixel offsets. You *will* look at this webpage this way and no other way (unless you want to write your own style sheet to use my horribly named DOM classes that is).

Just try to increase the font size on any "modern" webpage and watch it utterly break.

We have jumped from enforcing design through diarrhea of the <TABLE> tag in the 90s, to enforcing design through obscenely complex CSS styles. It's the same damn thing.

Publishing on the Web Is Different!

Tips about how to make websites more readable for web crawlers as well as human's with disabilities who may be using different user-agents.

Advice includes:

*proper ways to construct alt text
*using title attributes in hyperlinks
*using link tags to denote forward, back, and up leveling
*proper tabel headers

Dive Into Accessibility: Making truely readable websites

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.