AJAX vs JSONP

[McDermott, Michael]

Tom,
Do you control all the domains in question?  If so, the scope of your
concern is probably greatly reduced.

Here's a pretty good stackoverflow primer on the subject:
http://stackoverflow.com/questions/613962/is-jsonp-safe-to-use

Mike




On Mon, Oct 24, 2011 at 8:34 AM, Lukas Hämmerle
<lukas.haemmerle at switch.ch>wrote:

> Allow me to add some points to this subject as we are one of those
> federations that use remote Javascripts for Discovery.
>
> Very simply put these are the gains of using JSONP/remote Javascript
> loading:
> - Ability to load data from remote sites.
> - Ability to load Javascript code from remote sites. This code can be
> generated dynamically and updated automatically be the maintainer.
> - Very convenient and easy to integrate a feature into many sites
>
> And the risks:
> - Including script tags from remote sites allows the remote sites to
> inject any content into a website.
> - Dependence on remote site's availability and security in general
> - If used by many sites, many sites will be affected immediately
>  by problems (Single Point of Failure)
>
> Loading executable code from Remote sites is always a risk. The question
> is if one can handle them and if the risks are acceptable taking into
> account the benefits. There are millions of web pages for whom the risks
> *are* acceptable. Just think of Google Ad Sense and similar services.
> They wouldn't work without loading remote Javascripts. On the other
> hand, Google certainly will make sure that their scripts are well
> protected because this is business critical for them.
>
> The same is true for all web sites that use hosted versions of JQuery,
> YUI and other Javascript frameworks. Their administrators  apparently
> think that the gains outweigh the risks (or they are just not aware of
> the risks or too lazy to download a local copy).
>
> In SWITCHaai we have been offering to our Service Providers a feature
> called Embedded WAYF since more than two years. It allows to embed the
> central wayf into any web page. In order to make this work, an
> executable javascript is loaded from our central WAYF.
>
> For the operators of an AAI service the Embedded WAYF is very valuable
> because the integration is very easy, they always have an up-to-date
> list of IdPs and they can customize their instance of the WAYF. The
> improved usability from having a WAYF integrated into a web page is also
> very much appreciated by all parties.
>
> Today about half of all observed login requests (total 1.5 millions) on
> our central WAYF are handled by the Embedded WAYF.
>
> In order to protect the Embedded WAYF, our central wayf service is
> provided by multiple instances in different geographical areas. Using
> anycast, several monitoring applications and an intrusion detection
> system that informs us about file manipulations, we try to ensure that
> the service is sufficiently protected.
>
> However, in the more than two years that we operated the Embedded WAYF
> we also have learned a few times about the things that can go wrong.
> So far all issues directly affecting the Embedded WAYF were related to
> configuration errors and bugs. Both of which affect any kind of
> software. The difference is that such issues become effective
> immediately on all sites that use the Embedded WAYF.
>
> The good thing though is that not only negative effects become effective
> immediately but also fixes for such issues. No need to make another
> release and redeploy of the software to fix the problem.
>
> So far the most serious WAYF incident in six years of production
> operation of SWITCHaai happened just a few weeks ago. But it had nothing
> to do with the remotely loaded javascript but with the architecture of
> our infrastructure.
>
> A DOS attack stopped hundreds of users from accessing their AAI services
> during some minutes because the WAYF was not or only very slowly
> responding.
>
> Although this incident had not directly to do with the Embedded WAYF, it
> demonstrated that a central service like our WAYF can be a risk to the
> infrastructure. The same would be true for a central federated error
> handling solution. On the other hand, error handling is probably not
> that critical given that the user already experienced another error that
> led him to the error handling page :-)
>
> Although we will continue to use the Embedded WAYF (and remotely loaded
> javascripts), we know that with the advent of Shibboleth 2.4 new
> approaches to solve the Discovery issue became available. Therefore, we
> are having a closer look at the Shibboleth Embedded Discovery Service
> because it gets rid of the above-mentioned risks (at the cost of some
> other drawbacks).
>
> Cheers
> Lukas
>
> --
> SWITCH
> Serving Swiss Universities
> --------------------------
> Lukas Hämmerle, Software Engineer, Net Services
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 64, fax +41 44 268 15 68
> lukas.haemmerle at switch.ch, http://www.switch.ch
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>



-- 
Michael J. McDermott
Lead Developer, Identity and Access Management
Brown University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/dev/attachments/20111024/b9ee5b0a/attachment.html