XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: Javascript and plugging holes

On Dec 9, 2010, at 17:48, Stephen Green wrote:

>> It's an accident of history that scripts, plug-in content and images from a different origin are allowed by default. If it were possible to plug this hole without Breaking the Web, it would probably have been plugged already.
>> 
> 
> Isn't it true that much of what is done these days with Javascript
> these days (jQuery, etc) is
> powerful because it exploits holes which haven't (yet!) been plugged?

Not really. Most of the features of jQuery operate within the DOM of the page and, thus, aren't exploiting any holes.

Only cross-domain loading of JSON-P/scripts could be considered a powerful feature that relies of a feature that would be considered a hole if introduced today.

Note that even though you can display images to the user cross-origin, if you paint a different-origin image onto a canvas, the canvas becomes tainted so that the script is not allowed to read data back from the canvas. This prevents cross-origin image information leakage.

If you load plug-in content cross-origin, the security characteristics depend on the plug-in.

> Isn't that one factor which gives JSON an edge on XML?

Pure JSON (as opposed to JSON-P) is subject to the Same-Origin Policy just like XML is unless the Same-Origin Policy is relaxed using CORS. OTOH, if you embed XML inside a JavaScript program (like JSON-P embeds JSON inside a trivial JavaScript program), you can load it cross-origin without CORS.

Basically, cross-site information leak avoidance depends on Web resources that contain private information not being valid JavaScript programs that reveal information to the global scope (in the JavaScript scoping rule sense) when evaluated. In practice, HTML, XML, PDF, Office, etc. files aren't such valid JavaScript programs. JSON-P resources are such programs by design.

> Maybe JSON and jQuery and the like
> are best kept to
> short-term goals but XML more likely to be used for longterm goals
> (like documents/archives)
> since there is the risk that the security concerns will eventually
> overrule the worry about
> Breaking the Web and holes will be plugged which break much of what is
> done today with
> Javascript/jQuery (even HTML5?) and JSON? (I hope I'm not spreading
> mere FUD by saying this).

I'd put that in the FUD category. It's not really feasible to change the defaults to block cross-origin script loads at this point.

However, Mozilla has Content Security Policies (Firefox 4-only at the moment) that allow sites to opt into more secure defaults as a defense-in-depth measure. (It's only defense-in-depth as opposed to plain defense, because the defense doesn't take effect in browsers that don't support Content Security Policies.)

https://developer.mozilla.org/en/Introducing_Content_Security_Policy

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS