[cors] security issue with XMLHttpRequest API compatibility

It looks like the client-side API for cross-origin messaging is the
same as the current XMLHttpRequest API. I think there's a security
issue with this decision. The current XMLHttpRequest implementation
drops any attempted cross-origin request. This implementation protects
a client-side application that inadvertently sends a request to an
unexpected target URL. Since the request is dropped by the browser
implementation, any client credentials (such as a password) in the
request body are not exposed to the wrong server. Since XMLHttpRequest
has, to date, provided this protection, client scripts have had no
real need to vet the URLs that they send messages to. Consequently, it
seems unlikely that these scripts do any vetting of their target URLs.
It may be possible for an attacker to cause a client script in another
domain to send a request to a target URL on the attacker's server.
Since the attacker controls his server, the resource can be marked as
accepting cross-domain requests. Since the client script wasn't
expecting such requests to succeed, it may include client credentials
in the sent request. Whether or not a particular web application is
vulnerable to this kind of attack requires studying the particular
application and how it obtains the target URLs that it sends requests
to, to see if there is an opportunity for an attacker to inject an
unexpected URL.

--Tyler

Received on Monday, 6 April 2009 18:30:22 UTC