Welcome to another edition of Security Corner. This month’s topic is cross-domain Ajax, and it’s specifically an introduction to a few of the security concerns that I hope to elaborate on in future editions. If you don’t use Ajax, don’t know what it is, or just believe it’s nothing more than the latest trend, you might think this topic is irrelevant to you. On the contrary, this is a common misconception that I hope to address. With a rich collection of client-side features supported by most modern browsers, attacks that target your users are becoming much more sophisticated, and as a web developer, you should be prepared.
What Is Ajax?
Ajax describes a collection of technologies that let clients communicate with a server without a page load. On the surface, this sounds like nothing new. What sets Ajax apart from traditional client-side technologies is the ability to both send and receive HTTP. This gives client-side scripts the ability to provide much richer user interfaces, but it also gives attackers another tool to use in exploits as well as some new potential targets.
The primary enabling technology is
Cross-Site Request Forgeries
Cross-site request forgeries (CSRF) can be described as any technique that causes an innocent victim to send an attacker’s request. In order to be sure that a user’s request is intentional, most developers use a one-time token (sometimes called a shared secret or CSRF token):
$token = md5(uniqid(rand(), TRUE));
$_SESSION['token'] = $token;
$_SESSION['token_time'] = time();
<form action="buy.php" method="POST">
<input type="hidden" name="token" value="<?php echo $token; ?>" />
<!-- … -->
This gives the developer something to check before taking an action.
- The same-origin policy does not apply to XHR.
Luckily, the same-origin policy does apply to XHR, so your only concern as a PHP developer is the presence of any XSS vulnerabilities in your applications. With the rise in popularity of Ajax, XSS vulnerabilities are more dangerous than ever.
There are quite a few creative techniques being used to work around the same-origin policy, and I’m only going to discuss a few this month:
- Application proxy
- IFrame proxy
The idea behind an application proxy is to have XHR send requests to a URL within the current domain, and a server-side script proxies that request to another domain. This is simple and effective, and it erases the primary security concerns, because the browser (or a rogue script) cannot make direct requests to the other domain.
src attribute of the
The last technique, using an IFrame proxy, is a bit more complicated to explain. It’s a clever hack, but because I promised not to veer off-topic, I’ll point you to a URL where you can learn more:
Although this technique does get around the same-origin policy, the inherent risk is mitigated, because it requires cooperation. An attacker cannot use this technique to exploit a site that doesn’t support it.
The documentation stresses the risks involved in implementing this technique on your own site:
You should not experiment with this technique unless you are very restrictive on the clients and API URLs that are allowed. Placing the Server document on your web server means opening up the allowed URLs to the world.
It might not seem important to consider the security implications of Ajax (and particularly cross-domain Ajax), but it is under either of the following two conditions:
- You enable cross-domain Ajax using a technique such as the IFrame proxy, where you allow cross-domain Ajax requests initiated from other domains.
- Your users have browsers that support Ajax technologies.
Because the second condition is true for almost all of us, cross-domain Ajax is a topic worthy of our attention.
Until Next Time…
The impact of Ajax and other emerging technologies and development methodologies is an interesting and evolving subject among web app security experts. Ajax has already enabled a few major exploits, because the target site was either vulnerable to XSS or allowed cross-domain Ajax requests.
The most important point I hope I have made is that you don’t have to use a technology in your own app in order for it to be relevant to you. Every new technology can be a potential tool used by attackers to develop new exploits, whether exploiting old vulnerabilities in new ways or creating brand new exploits.
I hope to continue this topic by describing some of my current research that has revealed a major security vulnerability in a popular Web 2.0 application.
Until next month, be safe.