Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] Maximally Consumable Data

From: "bryan rasmussen" <rasmussen.bryan@-----.--->
To: "Manfred Staudinger" <manfred.staudinger@-----.--->
Date: 4/7/2008 8:47:00 PM
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
>  >
>  >
>


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent