Re: [xml-dev] Re: Javascript and plugging holes

[Henri Sivonen <hsivonen@iki.fi>]

On Dec 10, 2010, at 09:36, Simon St.Laurent wrote:

> On 12/10/10 10:02 AM, Stephen Green wrote:
>>> At the same time, Mobile Device manufacturers are pushing for the opposite.
>>> They want JS to do MORE not LESS.
>> 
>> The virus-script-kiddies haven't paid so much attention to smartphones
>> yet, I guess.
> 
> There are lots of security holes in JavaScript and the Web environment, and many of them happen to work on phones too now.

I think saying that there is a lot of holes is a mischaracterization. Rather, there are a handful of fundamental big gotchas that require Web app developers to be careful in order to be able to write apps that don't have information leaks and don't enable unauthorized actions given the way the Web's security model is.

It's virtually impossible to fix the fundamental gotchas, because people really like to exploit them for convenience in non-malicious ways. Even in this thread, there's been the undertone that browsers are somehow being anti-XML when they enforce the Same Origin Policy for XHR. The restriction isn't there in order to be annoying. It's there for security. When a restriction is missing, people love to exploit the lack of restriction e.g. by including scripts and images cross-origin from CDNs or by POSTing forms cross-origin. If XHR hadn't been Same-Origin early on, people on this mailing list would have been using it cross-origin all over the place and it would be impossible to "fix" it without breaking too many sites.

> This is a known problem - Douglas Crockford (creator/extractor of JSON) spoke about it at XML 2007, and there's some discussion of it in this interview too:
> 
> <http://answers.oreilly.com/topic/1483-doug-crockford-discusses-javascript-html5-security-issues/>
> 
> I'd watch all of it, but security comes up around 2:12 and 4:23 in an HTML5 context.

Crockford makes what he says sound profound, but in that interview, he made two actual suggestions:
 1) Stop and fix security first.
 2) Use the security model of Google Caja.

I general, suggestions of the form "drop everything until you've addressed my concern" isn't really a realistic way to do things. It's pretty sad that people take Crockford seriously on that type of rhetoric.

As for "let's use this other security model instead", it's not really realistic to take a massively deployed system and swap out its fundamental security model. (It might be possible to let sites optionally relax the Same Origin Policy in Caja-esque ways and Content Security Policies may have success in optionally restricting things for defense-in-depth, but making security policies more "flexible"--i.e. complicated--means even more ways for Web app developers to shoot selves and their users in the feet.)

I expect you haven't seen this less polite take on Crockford's writing on the topic: 
http://diveintomark.org/archives/2008/02/21/the-bolero-of-troll

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/