[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Maximally Consumable Data

• From: "Manfred Staudinger" <manfred.staudinger@g...>
• To: "bryan rasmussen" <rasmussen.bryan@g...>
• Date: Tue, 8 Apr 2008 00:12:46 +0200

Thanks for your kind answer.
- assuming XMLHttpRequest would allow for XD requests, then would this
make possible an attack which would not be possible if the very same
XML would be sent with JSON?
- what is the main reason, why XD JavaScript is allowed?
- is the attraction JSON receives mainly because it let web designers
bypass the XD restriction on XML ("Maximally Consumable Data")?

Manfred

On 07/04/2008, bryan rasmussen <rasmussen.bryan@g...> wrote:
> 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@g...> 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@g...> 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@m...> 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@l...
>  >  >  >  subscribe: xml-dev-subscribe@l...
>  >  >  >  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@l...
>  >  >  subscribe: xml-dev-subscribe@l...
>  >  >  List archive: http://lists.xml.org/archives/xml-dev/
>  >  >  List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>  >  >
>  >  >
>  >
>

• Follow-Ups:
  • Re: Maximally Consumable Data
    • From: "bryan rasmussen" <rasmussen.bryan@g...>

• References:
  • Maximally Consumable Data
    • From: "Costello, Roger L." <costello@m...>
  • Re: Maximally Consumable Data
    • From: "bryan rasmussen" <rasmussen.bryan@g...>
  • RE: Maximally Consumable Data
    • From: "Costello, Roger L." <costello@m...>
  • Re: Maximally Consumable Data
    • From: "Mukul Gandhi" <gandhi.mukul@g...>
  • RE: Maximally Consumable Data
    • From: "Costello, Roger L." <costello@m...>
  • Re: Maximally Consumable Data
    • From: "bryan rasmussen" <rasmussen.bryan@g...>
  • Re: Maximally Consumable Data
    • From: "Manfred Staudinger" <manfred.staudinger@g...>
  • Re: Maximally Consumable Data
    • From: "bryan rasmussen" <rasmussen.bryan@g...>