XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Maximally Consumable Data

The difference is that getting JSON by using a JavaScript from another
server opens you up to an XSS attack if that server is compromised, or
if the service which provides the JSON output is taken over by a bad
actor by purchasing of domain name etc.

The XML based service is also open to attack, but can be better
defended against (attacks I am thinking of are entity based, for
example. which can be shut down server side by setting what the parser
allows)

The XML also allows for validation of format etc. How are you going to
validate your JavaScript is just a JSON object when you use

<script src="http://remote.eviljavascript.com/grabbingyourapplicationdata.js";>

(actually IIRC it is now possible to do that by specifying that the
language attribute on the script corresponds to a JSON mimetype but
even if it is possible I would hate to rely on that currently)
Cheers,
Bryan Rasmussen




On Mon, Apr 7, 2008 at 9:59 PM, Manfred Staudinger
<manfred.staudinger@gmail.com> wrote:
> If I want to consume a web service which offers XML, then I'm forced to go
>  to my server, request the XML to be sent to it, and then deliver it client side
>  (or is there a better way?).
>  If I do it this way, where is the gain in security?
>
>  Manfred
>
>
>
>  On 07/04/2008, bryan rasmussen <rasmussen.bryan@gmail.com> wrote:
>  > anyway it is a security hazard because when you do that the script
>  >  executes when you get it, That you are getting JSON in this way does
>  >  not change the fact that you are allowing a JavaScript to execute
>  >  inside of your client side application spac, opening up for all sorts
>  >  of attacks. However there is some interesting work being done that
>  >  may, at some point, allow one to get around this problem - look at
>  >  CAJA. However currently I stand be earlier statement that the XML is a
>  >  better solution because of better security control of data entering
>  >  into the application.
>  >
>  >  Cheers,
>  >
>  > Bryan Rasmussen
>  >
>  >
>  >  On Mon, Apr 7, 2008 at 8:18 PM, Costello, Roger L. <costello@mitre.org> wrote:
>  >  > Hi Mukul,
>  >  >
>  >  >
>  >  >  > IMHO, what's different (great) about this scenario?
>  >  >
>  >  >  I need to give more detail about how it works.
>  >  >
>  >  >  A JavaScript Ajax application that is running in a browser can only
>  >  >  fetch data from the domain that it came from.  It does this using the
>  >  >  XMLHttpRequest object.
>  >  >
>  >  >  Quoting now from Bulletproof Ajax:
>  >  >
>  >  >  "We can't use XMLHttpRequest to access the Web APIs offered by so many
>  >  >  sites these days.  That's a real shame because most APIs return their
>  >  >  data in XML, which would be available in responseXML.
>  >  >
>  >  >  The script element has no such security restrictions.  It's possible to
>  >  >  access a JavaScript file from another domain in this way:
>  >  >
>  >  >  <script type="text/javascript"
>  >  >
>  >  >  src="http://www.xfront.com/us_states/json/javascript/us_states.js";></sc
>  >  >  ript>
>  >  >
>  >  >  If you can request a JavaScript file from another domain, then you can
>  >  >  also request a JSON file.  Remember, JSON is nothing more than
>  >  >  JavaScript."
>  >  >
>  >  >  -- the author shows how this can be generated dynamically --
>  >  >
>  >  >  Thus, through this technique, the JavaScript running in your browser
>  >  >  can pull in data from any web service that serves up JSON (such as the
>  >  >  Yahoo web services).
>  >  >
>  >  >  /Roger
>  >  >
>  >  >
>  >  >
>  >  >  _______________________________________________________________________
>  >  >
>  >  >  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]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS