- From: Tyler Close <tyler.close@gmail.com>
- Date: Mon, 6 Apr 2009 11:29:43 -0700
- To: public-webapps@w3.org
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