[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Javascript and plugging holes
> 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: 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 > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|