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

[Stephen Green <stephengreenubl@gmail.com>]

> 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.
>

OK, I'm no expert on all this but from what I've seen it looks to
me like Javascript is allowed to do things (and jQuery makes use
of this) which other technologies like CSS are sometimes
forbidden to do. It's an out-of-date example but I remember some
issues over CSS pseudo elements which were, I thought, not
allowed in some browsers because, I assume, they caused
security concerns with allowing elements to be inserted from a
file outside the webpage (even if it is in the same domain). Even
now I get problems with jQuery if changing elements where any
CSS processing is invoked, and I've taken this to be because the
CSS processor has to be very cautious, but the same changes
are allowed without any problems when no CSS is involved. I'm
thinking that CSS implementations in browsers are more cautious
because someone sat down and said what was risky and what
wasn't, while Javascript doesn't seem to me to have yet been
put to the same scrutiny. That might come later and break jQuery.
Can anyone back this up with better facts/examples? It is always
the pwoer of a scripting language that makes it a security risk as
the script kiddies writing and reusing viruses get to be able to do
things they can only wonder at. Declarative languages seem far
safer because there is more control in the processor in how they
achieve their end result: So it seems to me. I hope that is obvious.

On the JSON, it still relies on newer browsers supporting native
JSON parsing and on some recent safer parsers than the initial
eval() which is considered unsafe. This means there are probably
quiet a few JSON implementations still using eval() either because
they haven't been changed to the safer parsers or because they
are being run in browsers other than the latest native-JSON ones.
So things are still in flux and someone might come along and plug
the security hole by stopping JSON using eval somehow and so
break many implementations out there which still rely on it. These
are just a couple of cases and cases come along all the time. I
did a quick search on 'Javascript security' and JSON came up
all over the place with warnings (especially about eval of course).

----
Stephen D Green



On 10 December 2010 13:37, Henri Sivonen <hsivonen@iki.fi> wrote:
> 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/
>
>
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>