Cross-Domain Ajax Insecurity

Chris Shiflett has posted his look today at cross-domain Ajax requests and some of the security implications that can come with it, especially in a world where more and more developers are beginning to think it's okay.
Since the birth of Ajax (the term, not the technology), there has been an increasing interest in various client-side technologies, especially JavaScript. Those who have forged ahead in an attempt to innovate new ways of applying Ajax have inevitably run into the same-domain security policy of XMLHttpRequest(). As a result, there has been an increasing demand for cross-domain Ajax, and there are several creative techniques in use today to get around the same-domain restriction (none of which I consider cross-domain Ajax).
He talks about other methods that can capture the data in an Ajax request (post scanner), but notes that one of the real dangers is removing a barrier for cross-site request forgeries that most normal sites already have in place. To illustrate, he mentions an issue Digg had with a "self-digging story" a little while back. He also includes a sort of how-to on the method that they used to accomplish the task - basically a Javascript form submit on each viewing. There are checks in place for it now, but there's still the same kind of issue with cross-domain requests. Sure, you'd have to lure diggers to another page to get the key required for another digg, but since the code runs on the client, digg doesn't have much protection.
It's worth noting that XSS vulnerabilities allow malicious JavaScript to execute within your domain, thereby avoiding the same-domain restrictions. This can have catastrophic consequences. Just ask Myspace.

Cross-Domain Ajax Insecurity

Chris Shiflett has posted his look today at cross-domain Ajax requests and some of the security implications that can come with it, especially in a world where more and more developers are beginning to think it's okay.

Since the birth of Ajax (the term, not the technology), there has been an increasing interest in various client-side technologies, especially JavaScript. Those who have forged ahead in an attempt to innovate new ways of applying Ajax have inevitably run into the same-domain security policy of XMLHttpRequest(). As a result, there has been an increasing demand for cross-domain Ajax, and there are several creative techniques in use today to get around the same-domain restriction (none of which I consider cross-domain Ajax).

He talks about other methods that can capture the data in an Ajax request (post scanner), but notes that one of the real dangers is removing a barrier for cross-site request forgeries that most normal sites already have in place.

To illustrate, he mentions an issue Digg had with a "self-digging story" a little while back. He also includes a sort of how-to on the method that they used to accomplish the task - basically a Javascript form submit on each viewing. There are checks in place for it now, but there's still the same kind of issue with cross-domain requests. Sure, you'd have to lure diggers to another page to get the key required for another digg, but since the code runs on the client, digg doesn't have much protection.

It's worth noting that XSS vulnerabilities allow malicious JavaScript to execute within your domain, thereby avoiding the same-domain restrictions. This can have catastrophic consequences. Just ask Myspace.


August 9th, 2006

Tagged View

Tags Similar

Posts Fresh +

Categories View