RE: [xml-dev] json v. xml

["Nathan Young -X \(natyoung - Artizen at Cisco\)" <natyoung@cisco.com>]

Hi.

After thinking about this I decided that the whole picture is fiendishly
complex.

Security:
 - as a surfer I don't want my browser to act against me
 - as a web application author I don't want my application to be
infected
   with code that does things I did not intend
 - as a web service provider I don't want my web service to be open to
   abuse (one man's idea of mash-up may be another corporation's idea
   of abuse??)

Hardwired security measures:
 - restrict the viewing experience of a given page to include only
   those things that come from the same server as the page itself
   - applies to XHR
   - applies partly to frames and iframes (you can request whatever
     you want but you can't see what you get back)
   - does not apply to img, js, css, etc
 - restrict requests to an outside server to a list of requests
   defined by that server to be valid targets to third party requests
   - implemented in newer flash plugins

Application level security practices
 - browser coding practices
   - don't translate user supplied arguments into file requests
   - don't eval JS from untrusted sources
 - server side practices
   - don't allow code in user supplied data that may be echoed back
     to the browser later
   - supply and verify one time tokens for form submissions
   - check referrers 

User practices
 - don't surf hacker sites with an active banking session
 - don't use IE
 - ok I'm getting silly


Sorry I don't have any concrete conclusions to draw here.

---->Nathan

.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:
||:.

Nathan Young
Cisco.com->Interface Development
A: ncy1717
E: natyoung@cisco.com  

> -----Original Message-----
> From: Rick Marshall [mailto:rjm@zenucom.com] 
> Sent: Friday, January 05, 2007 11:08 PM
> To: Nathan Young -X (natyoung - Artizen at Cisco)
> Cc: noah_mendelsohn@us.ibm.com; Len Bullard; Rick Jelliffe; 
> xml-dev@lists.xml.org
> Subject: Re: [xml-dev] json v. xml
> 
> Hi Nathan
> 
> You're right - what a pain - I was going to use that - now 
> I'll have to 
> make calls to my server so it can make the calls to the other 
> servers :( 
> or just put in iframes ;)
> 
> At any rate it's just another arms race
> 
> PS JUMP? http://xml.coverpages.org/draft-sayre-jump-03.txt 
> the wheel is 
> being reinvented already ...  <sigh />
> 
> Nathan Young -X (natyoung - Artizen at Cisco) wrote:
> > Hi.
> >
> >   
> >>> XML can be retrieved using the XmlHttpRequest, but only 
> >>>       
> >> from the same
> >>     
> >>> server the page in which the JS is running comes from.
> >>>   
> >>>       
> >> Not true - that's the whole point for doing mashups. And 
> you can use 
> >> XmlHttpRequest in effect to get or send anything.
> >>     
> >
> > I agree that XmlHttpRequest can get any kind of content 
> that resides at
> > a URL.  
> >
> > I still maintain that XHR can only be used back to the same 
> server the
> > page originated from, was that part of your disagreement?
> >
> > The rest of your points are well taken...
> >
> > ---->N
> >
> >   
> >> JSON and XML aren't 
> >> the security problem XmlHttpRequest is. In particular it can 
> >> be run from 
> >> "onload" in the body tag which means the poor user is screwed 
> >> from the 
> >> minute they access the site.
> >>
> >> Can we just clear up a few more things: 1. JSON is data 
> >> structures (like 
> >> XML) not objects (CS 101 - where are 
> create/destroy/methods etc?). 2. 
> >> Like it or not, verbose end tags means XML has a degree of 
> redundancy 
> >> that ensures correct structure - {} do not do that - and in large 
> >> documents and data files I see this as critical. 3. JSON also 
> >> includes 
> >> lots of useless redundancy - " everywhere is just the start, 
> >> so are the 
> >> limited and simple data types (why not include dates and 
> times? it is 
> >> the 21C after all).
> >>
> >> Rick
> >>
> >>     
> >>> JS (including JSON) can be included in the page using the 
> >>>       
> >> script tag or
> >>     
> >>> a DOM equivalent created via JS in the page.  The source 
> >>>       
> >> from which the
> >>     
> >>> script tag pulls a file full of JS source code can point to 
> >>>       
> >> any server.
> >>     
> >>> The fact that your page can easily get JS from untrusted 
> >>>       
> >> sources but not
> >>     
> >>> XmlHttp content is bizzare as far as I'm concerned.  
> >>>       
> >> Changing browser
> >>     
> >>> policies to tighten the restrictions on the scrip tag is 
> unlikely to
> >>> happen.
> >>>
> >>> For security, I think filtering so that your JSON or JS 
> always comes
> >>> from a trusted source is more important and more possible 
> >>>       
> >> than filtering
> >>     
> >>> the JS/JSON once it gets to the browser.
> >>>
> >>> Just for the record, I think the "v." in the subject line 
> >>>       
> >> of this thread
> >>     
> >>> is a mistake.  There is no generic JSON versus XML debate 
> >>>       
> >> outside of the
> >>     
> >>> context of a particular problem.  The set of solutions 
> >>>       
> >> where you'd hold
> >>     
> >>> both technologies side by side and compare their fitness 
> is a small
> >>> subset of all XML uses.
> >>>
> >>> --->Nathan
> >>>
> >>>   
> >>>       
> >>>> 2. If so, am I the only one who thinks this is bizarre?  
> >>>>         
> >> Whatever the 
> >>     
> >>>> history of these policies, we have a situation in which 
> >>>>         
> >> information 
> >>     
> >>>> transmitted in the form of an executable Turing-complete 
> >>>>         
> >> programming 
> >>     
> >>>> language (JavaScript) are allowed, but in which information 
> >>>> in the form of 
> >>>> a declarative markup language are blocked as a security risk?
> >>>>
> >>>> Now, I'm not against JSON.  The other good reasons for its 
> >>>> use have been 
> >>>> mentioned in this thread.  I also understand that anyone with 
> >>>> any serious 
> >>>> interest in security will not blindly eval whatever they 
> >>>>         
> >> get back as 
> >>     
> >>>> purported JSON, that the JSON subset of JavaScript is indeed 
> >>>> declarative 
> >>>> and not even close to Turing-complete.  I even agree that one 
> >>>> can transmit 
> >>>> Turing-complete code as XML (XSL comes to mind, or you can 
> >>>> put C Code in 
> >>>> into CDATA I suppose.)  The point is that almost no 
> >>>>         
> >> sensible default 
> >>     
> >>>> processing of XML raises the same sorts of security issues 
> >>>>         
> >> that would 
> >>     
> >>>> normally be associated with executing arbitrary JavaScript, 
> >>>> and we all 
> >>>> know that one of the ways to try and trick a JSON client is 
> >>>> to send it 
> >>>> non-JSON JavaScript..
> >>>>
> >>>> So, insofar as my sketchy understanding of the situation is 
> >>>> correct, and 
> >>>> blithely ignoring the many compatibility issue that 
> >>>>         
> >> prevent sensible 
> >>     
> >>>> changes to already-deployed systems, wouldn't it make sense 
> >>>> to ensure that 
> >>>> the security limits on cross-site downloading of script 
> >>>> fragments such as 
> >>>> JSON are at least as tight as those on XML?  Then, insofar as 
> >>>> cross site 
> >>>> access to JSON survives such changes, we could go back to 
> >>>> letting users 
> >>>> choose whichever format makes them happier in a given situation.
> >>>>
> >>>> Noah
> >>>>
> >>>> --------------------------------------
> >>>> Noah Mendelsohn 
> >>>> IBM Corporation
> >>>> One Rogers Street
> >>>> Cambridge, MA 02142
> >>>> 1-617-693-4036
> >>>> --------------------------------------
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> ______________________________________________________________
> >>>> _________
> >>>>
> >>>> 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
> >>>
> >>>
> >>>   
> >>>       
> >
> > 
> ______________________________________________________________
> _________
> >
> > 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
> >
> >
> >   
>