Re: [xml-dev] Maximally Consumable Data

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

On Tue, Apr 8, 2008 at 12:12 AM, Manfred Staudinger
<manfred.staudinger@gmail.com> wrote:
> 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?

Well since JSON sent in the way Roger describes is JavaScript, inside
of a JavaScript element that is executed in the context of the page
then I don't think it makes possible the self same attacks. I think,
personal opinion without having done any extensive reasoning on the
matter, that the executable JavaScript must be more dangerous than
just XML. However I believe that the reason for not allowing cross
domain XMLHTTP was due to concerns about possible data attacks of some
sort - although I can't remember what. Obviously though since XMLHTTP
can do more than return XML it might be that the concerns had
JavaScript or other possible attack vectors in mind as well that I
haven't even thought of.
>  - what is the main reason, why XD JavaScript is allowed?

No idea. As a general rule however the examples of XSS attacks are not
due to external JavaScript in the way Roger describes, although IIRC
there was an example some time in the last year where O Reilly were
using  JavaScript hosted on another server that caused problems of a
security nature when the service changed over to somewhat bad hands.

However IIRC there are security settings that will turn off
JavaScripts that do not come from the same domain anyway. This can
sometimes create problems in Web Analytics when client side analytics
tools are used, like Google Analytics - as an example problem.

Probably one reason why it is allowed is it is just too useful to
disallow, and is too built into the general fabric of things to
deconstruct at this date.
>  - is the attraction JSON receives mainly because it let web designers
>  bypass the XD restriction on XML ("Maximally Consumable Data")?
>

No I don't think so. JSON is used mainly because it is in some cases
less verbose and it is easier for JavaScript developers to work with
and understand (IMHO, actually I rather find it enjoyable as well). In
fact aside from Roger's example if I get XML from an external service
I have no problem returning it to my client side application as JSON
after running through a quick transform (except for possible encoding
situations that might apply), I do however have a problem using the
<script src method outlined in the earlier mail, cause while easier in
the short run doesn't seem to me to give that much more ease to be
worth possible headaches on some day way later when I won't be able to
figure out why everyone is complaining about the popup porn adds on my
weather and local traffic mashup. (to make an undoubtedly paranoid and
amusing scenario up for illustrative purposes)

Cheers,
Bryan



>
>
>  Manfred
>
>  On 07/04/2008, bryan rasmussen <rasmussen.bryan@gmail.com> 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@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
>  >  >  >
>  >  >  >
>  >  >
>  >
>