Cross Site Scripting, XSS
Todays websites are more complex than ever, creating a much better user experience. At the same time PHP has grown increadibly popular, allowing (imho) less skilled developers create professional applications. This is good, or is it?
Don't get me wrong, learning by doing is a great way of learning... and doing. But there are dangers out there that people don't even know about while they are developing a CMS, shopping cart or whatever. One of them are XSS, or Cross Site Scripting.So, what is XSS?
In my oppinion, XSS does not exists, it happens. XSS is when a web based applications allows malicius data from a user appear as valid data from the website. Let's lookt at en axampe:
ACME bulletin bord allows Bob to post javascript in his post. Eve visits reads Bobs post, and his javascript is executed by her browser, allowing Bob to hijack her account by stealing her username and password from her cookies.
What to do?
As a developer the one thing you need to do is escape your output. Let's look at another example:
ACME bulletin board want add a seach, so that Bob and Eve can serch trough all the posts ever made. So their developer starts coding a kick ass search function:
/**
* Kickass search function that we do not care about
*/
echo "Your search for ".$_GET['q']." returned $numResult posts.";
/*
* Display results, again we don't care
*/
?>
Now, if a user searched for <script language="javascript">insert bad code here</script>, that code would be treated as legemit code from the website.
If you ask yourself: "Why do I care, let the user attack him self, why do I care?" you should probably find something else to do. Or read on.
The attacker can offcourse create a link on his homepage, or send out a mass email containg a link to ACME bulletin board containing this bad code. Is a user visits the link all the cookies for ACME bulletion board is emailed to the attacker. And often cookies contains usernames and passwords, don't they?
And the user won't eaven notice, all they see is the ACME bulletin board search page, just what they were expecting.
It takes a while, and the security hole is published on bugtraq, and someone forwards the publishion to the devloper. Sure, he is not stupid, so he updates the search function, not only fixing the hole, but increasing the usability of the search function.
/**
* Kickass search function that we do not care about
*/
echo "Search for:<input type='text' name='q' value='".$_GET['q']."'>";
/*
* Display results, again we don't care
*/
?>
So the next time a user follows the malicios link, all he get is a textbox with some javascipt inside, nothing dangerous. That's what the developer thinks anyways. But he is wrong. The attacker has both experience, and understanding. So he just changes his link to:'><script language="javascript">insert bad code here</script> a opperation that takes him 20 seconds. Now, again the code will be executed. Why? Because the attacker closes the <input> tag first, then the malicios code is added.
Now, one solution to the problem, a smart solution would be:
/**
* Kickass search function that we do not care about
*/
echo "Your search for ".htmlentities($_GET['q'])." returned $numResult posts.";
/*
* Display results, again we don't care
*/
?>
htmlentities -- Convert all applicable characters to HTML entities
That's it for now, keep you koding safe!
Post new comment