Thursday, November 8th, 2007

Making JavaScript Safe With No Script

Category: JavaScript

Douglas Crockford really wants to make JavaScript safe and you can tell that he is frustrated in his new post on No Script:

I like JavaScript. The language’s design got a lot of things right. But it also got a lot of things wrong. Most of those wrong things are just annoyances. A lot of them can be avoided.

There is one problem in JavaScript that is bigger than all of the others put together: The Global Object. All compilation units are thrown into a shared global container. This gives each unit full access to all of the other units. All units get exactly the same rights and privileges. This turns out to be a huge mistake. It is the root cause of most of the security problems in the browser.

If evil script gets onto a page from a good site, the evil script can access the server and there is no way that the server can see that it is talking to an evil script. The script also gets control of the screen, and the user is also unaware of that. This is known as the XSS attack.

If you happen to land on an evil page, script on that page can access servers that you have visited (such as your bank’s website), and again, the server cannot tell that it is talking to an evil script. This is known as the XSRF attack.

Fortunately, there is an extension to Firefox that can significantly reduce the dangers and annoyances to you. It is called No Script. No Script lets you set policies on what scripts you want to run. It can block scripts from evil sites. It can frustrate some XSS attacks. It can also frustrate some phishing exploits.

It creates an (S) icon on the bottom bar that gives you access to an easy-to-use policy editor. You must explicitly authorize scripts for each of the sites you usually visit. You can grant temporary authorization for sites you visit once. You might think that you would have to spend a lot of time managing the policy, but surprisingly, you don’t.

In the long term, I want to replace JavaScript and the DOM with a smarter, safer design. In the medium term, I want to use something like Google Gears to give us vats with which we can have safe mashups. But in the short term, I recommend that you be using Firefox with No Script. Until we get things right, it seems to be the best we can do.

Posted by Dion Almaer at 11:32 am
22 Comments

+++--
3.9 rating from 28 votes

22 Comments »

Comments feed TrackBack URI

Love it — used it for years. Although I’ve found that just allowing all top-level sites by default (blocking all off-site scripts) and not trying to manage a potentially huge whitelist to be a LOT easier, especially for novice users.

Comment by mdmadph — November 8, 2007

NoScript seems to be one of the most popular extensions from the Firefox repository. So my assumption is this: a lot of people use it and do not grant access to JS on less known sites. So, it is becoming a necessity to use progressive enhancement. Libraries like Ext seem to totally ignore this approach. Try any of their demos and you’ll end up watching the loading indicator forever or read a heartwarming “JS … will make your life much easier” at the script.aculo.us site. This is not to blame these particular libraries specifically, as all of the JS frameworks are actually made for Javascript libraries. But it seems a lot of us forget about building something that takes accessibility seriously. Both http://www.w3schools.com/browsers/browsers_stats.asp and http://www.upsdell.com/BrowserNews/stat_trends.htm indicate that currently, 6% of web users don’t have JS. That’s more than the total market share of Safari and Opera together!
Shouldn’t we forget about our favorite scripting languages and focus on what degradability every once in a while?

Bernd

Comment by bmatzner — November 8, 2007

sorry, instead of “the JS frameworks are … made for JS libraries” I meant to say “JS aficionados”.

Comment by bmatzner — November 8, 2007

…I notice Dojo takes accessibility seriously in their latest release (1.0): http://www.sitepen.com/blog/2007/11/05/announcing-dojo-10/

Comment by Mark Holton — November 8, 2007

@bmatzner: That 6% being bots disguised as real browsers. There couldn’t more than 1% of internet users bumbling around the net with javascript off and not knowing it.

At this point, it’s like saying we should design sites in 16 color so that they look good on CGA screens for the infinitesimal percentage that surely still use CGA screens. You wouldn’t degrade the experience for 99% of your visitors in the hopes of making tiny 1% happy.

It just doesn’t make sense to spend dozens or hundreds of hours making a beautifully usable site degradable for a fraction of the 1% of the potential audience out there, many of who whom will probably never even visit the site in their lifetimes.

Comment by Brian — November 8, 2007

@Mark
apart from their E-Mail client demo currently being totally broken in IE, if you turn off JS in Firefox (which is what this post is about), it doesn’t work at all. Something that doesn’t work under forseeable circumstances is NOT accessible. While I appreciate their initiative to embrace WAI recommendations, accessibility of Javascript applications is not about color schemes. What good is all the sophisticated ARIA stuff when your app breaks down for people who happen to choose a certain browser or reduced browser feature set, such as JS off?

Comment by bmatzner — November 8, 2007

@Brian
Isn’t accessibility about removing barriers for the fraction of people who are confronted with those barriers? How many % of web users are actually disabled one way or the other? Wouldn’t you agree that a reduced feature set for blind or Safari users or bots (think SEO) would be well worth the effort despite their small percentage of the total web population?

Comment by bmatzner — November 8, 2007

A little ironic:
http://ajaxian.com/archives/walking-in-others-shoes-turn-javascript-off-for-a-day sixth comment (However, I admit No Script is different than turning off JS, just thought it was amusing).
I totally agree with Douglas that would need a decent mechanism for sandboxing (and Gears has a great one in WorkerPool).

Comment by Kris Zyp — November 8, 2007

I stopped here:

There is one problem in JavaScript that is bigger than all of the others put together: The Global Object. All compilation units are thrown into a shared global container. This gives each unit full access to all of the other units.

Does anyone think about const FireFox and Safari keyword?

Does anyone think about ES4 and namespaces ?

I really can’t understand Douglas Crockford position about JavaScript … He talks about problem disappeared from many month in updated browsers such FF or WK while “He doesn’t want to know anything” about ES4 and its ES3 bug fix features, included possibility to forget global scope assignment (thanks to const and/or namespaces).

IE accept const only in its totally reserved VBScript space
execScript(“Const TRY_TO_MODIFY_ME = 123”, “VBScript”);
alert(TRY_TO_MODIFY_ME);
TRY_TO_MODIFY_ME = 456; // throw an error
but VBScript is compatible with JS only with scalar variables (I created a cross-browser define PHP like function few days ago):
http://webreflection.blogspot.com/2007/10/cow-javascript-define-php-like-function.html

So, what are We talking about when “We” would stop ES4 implementation?
Please Douglas, I really respect You but this time I can’t understand your way.

Comment by Andrea Giammarchi — November 8, 2007

By my opinion JS security does not matter that much. Just don’t put security relevant stuff on the client side. User verification and authentification still has to be placed on server side. Just use JS for dumb RIA btw just for verification of correct user inputs (‘please enter 5 digit number’…) Second/final validation still has to be placed on server side!
I like global object manipulation very much for JSUnit-Testing vs. heavy weight AOP – for example – on server side for db backend-testing/using/simulation.
If logic is put on client side back doors are opened wide.

Gordon

Comment by gordon — November 8, 2007

P.S. ES3 *Monkey uses defineSetter (watch Object.prototype too) that could make function change/assignment safe against obtrusive malicious code … I think that No Script is a really cool stuff but if JS will be a better language (ES4) it shouldn’t be so useful, at least not for today problems.

Comment by Andrea Giammarchi — November 8, 2007

@gordon, I agree with You. Security is a server-side problem, not a client side one.
However We just have private scope variables to make some operation more secure even with JS but it should be a plus, not the only logic of a secure application, just a better logic for users that compile forms or use admin areas or something similar.

At the same time, an improved JS version should care about common problems too but it seems that this will be evil and not a good point to re-integrate a better JS in a business logic.
That’s what I think is quite strange (non-sense is a better description of my opinion).

Comment by Andrea Giammarchi — November 8, 2007

Installing NoScript is hardly a solution for the novice user. Having them understand that the reason a page “doesn’t work” is because it needs JavaScript, instead of it just being malformed HTML or a poorly designed site is hard enough.

Comment by Jordan — November 8, 2007

How ironic to hear security mumbling from the creator of JSON :D

Comment by Mathieu 'p01' Henri — November 9, 2007

I don’t get why Douglas is taking this position… inciting people to use NoScript will only degrade their “web2.0” experience and will make them see broken sites instead of fully working ones.
This is almost 2008, no average Joe disables javascript on purpose because 99% of the times they don’t even know what it means or what it does.
Time to stop scaring people away from javascript, let’s better teach good use of it and secure our routines so that any kind of XSS attempt is futile.

Comment by gonchuki — November 9, 2007

@Brian I’ve found that progressive enhancement (as opposed to graceful degradability) reduces development time and produces cleaner code.

Your alpha users, the people you probably *really* want to impress, are using NoScript. We notice when your kewl new app is broken with js turned off. If it’s kewl enough, okay, you get temporary scripting. Otherwise, you get written off as an amateur who doesn’t understand the very real (and legal) need for accessibility.

Same with Flash, by the way. Flash is necessary for some apps (YouTube!) but not for most.

Comment by Chris Snyder — November 9, 2007

“We notice when your kewl new app is broken with js turned off.”

Just like you’d notice the site being broken if you access it from lynx or ancient versions of Safari or how you’d notice that a trip across country takes much longer in a Model-T than in a Ferrari. “Alpha” users who show off their prowess by disabling Javascript don’t impress me in the least.

Accessibility, in terms of the disabled, is relative to how advanced their screen readers are. In the beginning, they couldn’t function with anything but basic HTML pages. Now there are screen readers that parse JS and even function on sites like Google maps.

I only began to feel this way in the last year or so, after seeing that non-JS users have nearly completely dropped off the map. It’s as much a standard as HTML and it’s silly to live in the past to please those who are to afraid to leave it.

Comment by Brian — November 9, 2007

How much of a problem is XSS and XSRF anyway? I understand the mechanics and that these things can happen, but are they actually going on. Are there malicious users out there hijacking insecure sites that then get information about other sites? Even if they access my history or something and find out where I bank at, I presume my bank has adequate server-side security measures.

In the grand scope of things (pun intended), javascript vulnerabilities as a security problem seem minuscule compared to not shredding documents prior to trashing and not securing your snail mail box. I wonder how many people with No Script installed don’t follow these precautions in real life.

Comment by dan — November 10, 2007

What is needed is an html tag with a paramter that tells the form not to execute scripts within the tag. The parameter will be a random one and will be created each time the page loads, so no one can manipulate the ending tag. for example imagine a webpage with tags:

This will prevent xss, or any other css/js injections like within user generated wysiwyg comments. no script inside these two tag will execute, and the unique key will be regenerated each time the page loads so the hacker will not be able to put a /noscript tag in his injection.

Comment by Yonig — November 13, 2007

since the last comment was torn by the sys, i meant for tags like
noscript key=”asdgfdsgfdgdfgfd”
and ending tag like
/noscript key=”asdgfdsgfdgdfgfd”

Comment by Yonig — November 13, 2007

That’s not so smart, stop being to paranoid!

JS is great, especially these days, USE IT!

Comment by Web Design NY — November 17, 2007

Making JavaScript safe by using an extension that turns it off! This is funny, especially hearing it come from Mr. JS.

Comment by Reinis — November 18, 2007

Leave a comment

You must be logged in to post a comment.