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

[Stephen Green <stephengreenubl@gmail.com>]

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

----
Stephen D Green



On 10 December 2010 14:58, David Lee <dlee@calldei.com> wrote:
> 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
>
>
>