Joe Walker - javascript tag

Comparing the Evolution of Java and JavaScript

Mon, 17 Dec 2007 13:19:28 GMT

Java:

Java is the most used language in the known universe. It is also a very simple* language. Some people believe that there is some scope in enabling Java to accommodate more programming styles (e.g. functional programming via closures). Others believe that being lightweight is a virtue.

JavaScript:

JavaScript is the most deployed language in the known universe. It is also a very simple* language. Some people believe that there is some scope in enabling JavaScript to accommodate more programming styles (e.g. by adding classical inheritance not just prototypal inheritance, and an optional type system). Others believe that being lightweight is a virtue.

Features:

It's interesting that the current simple version of JavaScript already has the features (i.e. closures) that people want to keep out of Java otherwise it will become too complex, and that Java already has some of the features (i.e. classical inheritance) that people want to keep out of JavaScript, otherwise it will become to complex.

Crossroads:

The Java language is challenged by languages such as Ruby, Groovy and even Scala, all of which support closures. The majority of people that have spent serious time with these languages prefer them over Java for at least some set of problems.

The JavaScript language is challenged by Silverlight. Microsoft try to avoid saying things like "death to Ajax", but secretly (or not so secretly depending on who you talk to) they would love to control the platform once more, and Silverlight is the latest attempt at regaining control.

Features vs. Complexity:

Joel noticed that there is a big difference between good developers and bad developers. Google noticed it with it's picky hiring process. On many projects there are a few developers that do all the real work, while others just slow things down.

But much of the "keep complexity out of the language" debate is aimed at helping the people that write less code anyway.

Nail-guns and angle grinders are dangerous tools, but the building trade accepts the danger in the name of greater productivity. In software development where the difference between good and bad developers is that much greater, and where developers don't actually get physically maimed, the argument for power over simplicity is that much stronger.

In summary, extra power helps smarter developers work more quickly, but makes life harder for less smart developers. Since a small number of smarter developers generally do better work than a large number of no so smart developers, we should tend slightly toward giving developers more powerful tools.

Java:

In Java, BGGA closures enable higher-order programming. It's hard to say that the addition of closures in and of itself would cause a complexity implosion, after all, Java is virtually the only modern day programming language without them. It could be argued that the Java language can't be evolved to accommodate them, but I'm leaning towards there being a net gain by including them.

Interestingly, Google Android contains a clean room re-implementation of Java. If Sun (or the JCP) accepts closures, and if (as seems likely) Google votes against them, what will happen to Android? Will it follow how Google votes, or how Java evolves?

JavaScript:

With JavaScript, people see a neat, compact language and fear it turning into Java. The good news is that it won't fully turn into Java because JavaScript already has closures and no one thinks they should be taken out ;-) The danger of the "features over complexity" argument, is that it can be applied indiscriminately, creating a monster, and the fear is that JavaScript will become a monster.

I'm gradually coming round to the opinion that many of the changes proposed to JavaScript actually reduce complexity. There are nearly as many frameworks that add classical inheritance to JavaScript as there are Ajax frameworks. Having one solution that we can all agree on can't be a bad thing even if you prefer prototypal inheritance.

*: For some value of simple. The exact definitions of simple used in these 2 paragraphs are not necessarily the same.

How to Protect a JSON or Javascript Service

Wed, 04 Apr 2007 08:32:14 GMT

There have been lots of explanations recently of the dangers of JSON or JavaScript remoting. This post is about what you can do to protect your scripts.

The Problem

The issues have been explained before, so I'm going to assume some knowledge of the problem. If you're not sure, some stuff to read:

I blogged that JSON is not as safe as people think it is, and updated it with more issues the next day. I've also written about CSRF too.
Dan Morrill has written an excellent and lengthy summary. The fixes are focused on GWT, but the issues are the same for everyone.
Brent Ashley has just published on developerWorks, about the future of cross-domain requests. The article is tangentially relevant, but there is a particularly good set of linked articles.

The Solutions

So what are the solutions? I think there are 3 options. Each has their pros and cons:

Use a Secret in the Request
Force pre-eval() Processing
Force POST requests

This post is a shortened version of the detailed description of what DWR does If you are interested in the options DWR takes and how you can configure it, you should read page.

1. Use a Secret in the Request

If you can only support one of these protections, this is the one to chose. Including a secret in the request allows the server to reject the request as invalid before any actions take place. It is common to include the secret in the URL, however this is a slightly vulnerable position for a secret since it is likely to turn up in web server log files and so on.

It is possible to use cookie values like PHPSESSIONID or JSESSIONID read using Javascript as the secret. The browsers cross-domain rules should prevent attackers from discovering this cookie. However this method will stop working as people begin to switch to using HttpOnly cookies. So it is better to start with a separate secret.

2. Force pre-eval() Processing

Since <script> tag remoting does not allow you to process the JSON or Javascript before it is eval()ed you can protect your JSON by forcing it to be manipulated before eval(). All 3 of these techniques will prevent your request from being pure JSON, however you may rank security above purity. There are 3 ways to do this:

Wrap the JSON in a comment. For example, /* { 'data':'protected' } */. When this is eval()ed, there will be no result, however if you have fetched the data using XHR or iframe, you can do some string manipulation before eval() to remove the leading /* and trailing */.
This method is good for plain JSON, however if you are using Javascript which could contain /* comments */, then you should not use this technique because comments in Javascript do not nest.
Prefix the script with 'while(1);' Since this is an infinite loop, if causes browsers to hang, and maybe give an error message. Either way the script does not get executed.
There is a potential vulnerability that some browser may allow you to override the action of while using something like this: 'function while() {}'. However I don't know of any such browser.
Google use this method to protect data in GMail. 'while(1);' is possibly better than 'while(true);' in case there are any browsers that allow you to redefine truth.
Prefix the script with 'throw new Error("message");'. This is a neat solution in that it allows you to explain what is wrong to users that get the message by mistake. DWR uses this method.
It is potentially vulnerable to some browser allowing an attacker to redefine the Error or String constructors to prevent the throw from happening, however this does not work on any browser that I know of, and it's hard to see how it could happen.

3. Force POST Requests

Since browsers use GET to process <script> tags, you can prevent <script> tags from working by denying GET requests for some JavaScript resource. This is the most common solution, however it is also perhaps the weakest.

Firstly XHR-POST doesn't work with older versions of Safari, so some support for GET is often useful.

More importantly future versions of Firefox are touted to include cross-domain XHR support. While we don't have exact knowledge of how this will happen, it would be foolish to base your security plans on this technique holding up.

Finally, we're working in an environment where new possibilities are popping up every day - betting your security on a system that works more by fluke than design isn't a great idea in my opinion.

By default DWR denies POST requests for belt and braces security, however this is customizable to allow support for older versions of Safari.

Operator overloading in Javascript 2 and a potential monster CSRF hole

Thu, 22 Mar 2007 13:10:15 GMT

I noticed that Javascript 2 might include operator overloading, including (at least) the ability to overload the < and > operators.

Operator overloading is really useful if you want to write a Complex number class, and really annoying when someone else wants to flex a newly learn skill and uses it for something totally inappropriate. Since authors of Complex number classes are less common than inexperienced programmers, I'm not keen on the idea in general purpose languages.

However, opinions about programming languages aside, I think that operator overloading in Javascript could turn out to be a really bad idea for a totally different reason.

The ultimate CSRF hack, when Javascript 2 comes out, might just be to redefine operators to make XML (or even HTML) a valid language.

You could then steal fairly much steal any cross-domain data by doing a script-tag include on an XML/HTML data source.

I really hope someone has thought of this...

Update: I can see that I didn't explain myself very well, so a quick update might be needed.

If you can overload the < and > operators then it might be possible to do so in such a way that HTML or XML becomes a valid bit of Javascript. This is more likely to be possible with known schema like HTML.

So how would this create a huge security hole? Simply because it would allow an attacker to use a script tag to include some HTML and then read the data using a combination of overloaded < and > operators and the Array/Object data stealing methods.

Currently CSRF is restricted to write-only exploits, and the standard way of protecting yourself includes using authentication data in a hidden form field. If an attacker could read this data too, then the standard protection against CSRF would fail. Also you could use this to steal data from intranets and, I'm sure, there are many other options.

The real worry here is that the designers of the language will, in one spec, have to out-smart crackers for a long time to come. Once websites start using the feature, it can't be easily removed.

Killing Blog Spam without Captcha

Thu, 18 Jan 2007 06:45:58 GMT

There are a few alternatives to Captcha - there is a nice trick that Damien Katz recently blogged about. It's ultimately doomed, because a spammer can easily adapt, but it is neat and it's working for now.

I've been mulling over a couple of ideas with Geert who was thinking of implementing the first for his Paste Bin site.

1. Use unpredictable form field names

When the user clicks on the "add comment" button, a comment form is presented with the usual fields: Name, Email, Website and Comment. The form fields however do not have predictable names. Instead, the fields are generated from some user-derived secret - maybe something stored in the users session. The important thing is that the field names are predictable to the server, but unpredictable to the user.

The server can then easily work out which field values relate to which input field, but the only thing you have to go on as far as HTTP stream goes is visually what labels are next to what fields, and there are plenty of ways to obscure this in HTTP. You can even alter the field ordering at runtime to make life even harder.

In order to submit the spam now, the spamming tool will need to manage cookies, visit a set of pages, and then guess which field names relate to which fields. This could be used in conjunction with fields hidden using CSS to make the guesswork near impossible.

2. Process the form with JavaScript

If the onsubmit process requires some JavaScript computation then the spammer will need to include a JavaScript engine in their toolkit for the post to be accepted. While it's possible that spammers could do this, maybe we can use this to slow them down to the point where it becomes less of a problem.

We dynamically create a short bit of Javascript that asks the posters browser to compute the factorials of some small prime. We can adjust the size of the prime to dictate the length of the required computation. The computation can be happening in the background while the post is being written.

I suspect that this method is slightly flawed because spammers will be using some bot-net to perform the attack, so slowing the submit rate down by 2 or 3 orders of magnitude isn't a big deal, they'll just use bigger bot-nets.

However the annoyance of having to include a Javascript engine in the spamming toolkit could easily stop all but the most persistent spammers.

The 4 States of Ajax Adoption

Wed, 20 Sep 2006 18:14:36 GMT

So the 4 states of Ajax adoption are as follows ...

1. Denial

Usually accompanied with an explanation like "Java Applets are better", or "Javascript makes your website inaccessible to blind people". (Generally I don't buy either argument although I can see a diminishing case for WebStart).

2. Progressive Enhancement

Means taking an existing JavaScript free website and adding some tweaks. It's a conservative approach that won't worry or annoy anyone, but it won't turn any heads either. The BBC, Wikipedia and EBay all use this approach because it's a safe thing to do with a big website.

3. Second Site

The problem with progressive enhancement is that it treats the minority noscript case first. The second site approach provides the best it can for the majority and for the minority too. Google, Yahoo and Amazon create far more advanced systems with this approach. It's likely to cost a bit more, but you're probably going to get a much better site out of it.

4. Accessible JavaScript

The full on approach tries to create accessible sites, but only when JavaScript is turned on. Microsoft's live.com, YouTube and some Google sites do this, and there are some UIs for which there is little choice. Anyone fancy creating office type functionallity without JavaScript?

You can work up the tree, starting out small and getting bigger, and the good news from a DWR point of view is that it can help you each step of the way. DWR is good for small tweaks and a more full on style.

What's your prefered approach?