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

["David Lee" <dlee@calldei.com>]

At the same time, Mobile Device manufacturers are pushing for the opposite.
They want JS to do MORE not LESS.

Palm's Web/OS can ONLY run JavaScript for a "native" application.  (but now
that HP bought Palm we'll see how that goes).

Android has a hybrid model but supports the "Pure JS+HTML" app model.   
 Other mobile OS manufacturers are seeing "JavaScript + HTML5" as the
solution for apps on mobile platforms.





----------------------------------------
David A. Lee
dlee@calldei.com
http://www.xmlsh.org


-----Original Message-----
From: Stephen Green [mailto:stephengreenubl@gmail.com] 
Sent: Friday, December 10, 2010 9:36 AM
To: Henri Sivonen
Cc: xml-dev@lists.xml.org List
Subject: Re: [xml-dev] Re: Javascript and plugging holes


Oh and another example - remember those high profile exploits on
Twitter where people inserted Javascript in their tweets and did
all sorts of 'wonderful'/naughty things. Not every company has the
kind of engineers around to plug such holes overnight like Twitter's
had to do so I imagine at some point the W3C or the like (or browser
vendors) coming under pressure to limit what the Javascript can do
as more and more people use it for HTML5, etc.
----
Stephen D Green



On 10 December 2010 14:33, Stephen Green <stephengreenubl@gmail.com> wrote:
>> 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
>>
>>
>

_______________________________________________________________________

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