[mashup-dev] WSAS Prominent Network Interface Re-direction inherited in the Mashup Server

[Jonathan Marsh]

It appears that the same origin policy is unable to distinguish different
names for the same origin (localhost, 127.0.0.1, the current IP).  By
definition these aren't different origins so while the policy might be good
from a security perspective, this is a bogus application of it.  The issue
arises when some, but not all, of the relevant URIs are redirected, fooling
the browser into thinking there are multiple origins.  I don't think we can
get the browser fixed (of course you could all switch to Windows and IE, but
that seems rather drastic ;-).  So I think we should look more closely at
our redirection strategy.

We need support for the following scenarios:

1) Online try-it.  User goes to
http://localhost:9762/services/myservice?tryit.  The try it page imports
?stub, which in turn contains absolute endpoint addresses such as
http://localhost:9762/services/myservice.  Regardless of any redirection
that occurs, the tryit should work every time regardless of changes in the
IP address (assuming the Mashup Server can dynamically change its IP along
with the rest of the computer).

2) Offline stubs.  User goes to
http://localhost:9762/services/myservice?stub and saves the result for
offline use, for instance in a desktop gadget (where there are no same
origin policies).  The endpoint addresses are now frozen, yet need to work
regardless of IP changes (i.e. they have to use localhost or 127.0.0.1).

3) Mashups.  A service calls another service running on the same Mashup
Server.  The endpoint addresses are hardcoded, yet must continue to work
regardless of IP changes.

I think these scenarios point to being able to use localhost throughout the
product - in accessing the management UI as well as the endpoint addresses.
The current redirection strategy seems to break that, and it's not clear why
it's necessary - it's introducing bogus differences in origin when it
doesn't seem necessary.  If I were able to access the console through
localhost, and the artifacts it handed back to me were from that same
domain, I could store them offline and use them effectively regardless of IP
changes.

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
 
> -----Original Message-----
> From: mashup-dev-bounces at wso2.org [mailto:mashup-dev-bounces at wso2.org]
> On Behalf Of saminda abeyruwan
> Sent: Friday, June 01, 2007 8:54 AM
> To: mashup-dev at wso2.org
> Subject: Re: [mashup-dev] WSAS Prominent Network Interface Re-direction
> inherited in the Mashup Server
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> In WSAS, we are enforcing this due to "Same Origin Policy:
> Protecting Browser State from Web Privacy Attacks". This has been
> enforced in Firefox 1.5 onwards.
> 
> For more info please refer to
> http://kb.mozillazine.org/Security_Policies
> 
> Thus, simply, if your machine has assigned an IP, Firefox doesn't allow
> you to fetch data from XMLHttpRequest, if loopback address is used.
> 
> The work around to these problems has been a simple redirection to the
> prominent address.
> 
> We didn't experience SOP problems in IE6 and IE7. (I'm a Linux guy :) )
> .
> 
> Thank you
> 
> Saminda
> 
> 
> Tyrell Perera wrote:
> > Hi all,
> >
> > I have noticed that since the Mashup Server is based on WSAS, it
> > redirects calls to the loopback address, to the prominent interface
> IP.
> > In other words, a user can not use 127.0.0.1 or localhost to connect
> to
> > the Mashup server.
> >
> > Since we are planning on allowing the users to install the server
> > locally in their individual machines, is this a vice approach?
> >
> > Consider a scenario where a user logs to a corporate network using
> DHCP.
> > This means his machine will have a dynamically allocated IP while on
> the
> > network and 'no IP' while disconnected. If this user tries to work on
> > the Mashup server while he is disconnected (i.e.; at home), he might
> not
> > be able to do so.
> >
> > I'm sure there is a valid reason behind the usage of this approach in
> > WSAS. But is it absolutely necessary on the Mashup server?
> >
> > Thanks,
> >
> > Tyrell
> >
> >
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFGYEEgYmklbLuW6wYRAkcxAJ9pcOi5+RCRaBBYRszu6CIU2GJIvgCfeVL5
> 7Nv0ai/4328O3iunZPYqS0c=
> =u4eD
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Mashup-dev mailing list
> Mashup-dev at wso2.org
> http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev