Cross-Site Scripting (XSS)

Cross-Site Scripting, abbreviated XSS, is another common security issue. This
issue is relevant whenever content that comes from the user will be redisplayed
on the screen. It is essentially when Javascript is injected into the HTML source.
We could for instance imaging a forum. On a forum users will be able to post
messages that will be displayed for other users. We want the users to be able
to format their messages and HTML is just perfect for that, right? There is
just a minor problem. . . Not all users are equally nice. The same kind of people that might want to drop the school's student table from the previous section
might also want to do something here. Speci_cally what they might want to
do is insert Javascript into the source. This might be for various purposes. It
could be simply for annoying by creating an in_nite loop of alert messages which
would force the user to shutdown the browser or it could be redirecting the users
to websites such as goatse or tubgirl (you might not want to check what it is
if you do not already know). Other, more so_sticated attacks, could be writing
a keylogger that logs and sends keystrokes (such as passwords) to an external
website or the injected Javascript could be retrieving the users' cookies (more
on the latter later in this tutorial).
XSS protection As a matter of fact, this is rather easy to protect yourself from as well.
PHP has a nifty function that is useful in this instance which is called htmlentities().
It will simply convert characters which have a meaning in HTML to their cor-
responding entities. For instance, HTML tags start with a lower-than sign and
that particular character will be converted to <. If you care about validation of your HTML (and you should!) then this will also help along with that.
We just have one problem. Our original example was a forum system and we wanted to give the users the opportunity to format their posts. However,the _x we just implemented removed this opportunity so we need to give them an alternate one. One with which we can control what they may do and not do.

A common feature is called bbcodes. It has a syntax very similar to HTML and
I am quite sure you are familiar with it if you have ever frequented any forum.
Be aware though! You might get some additional XSS security holes with some
tags.
A common bbcode tag is the URL tag. We could imagine that someone en-
tered [url=http://www.phpfreaks.com]The best PHP website[/url] which
would be converted to: <a href="http://www.phpfreaks.com">The best PHP
website</a>. At _rst glance there is no issue with allowing that. However,
URLs like javascript:alert('Hi') are also allowed and they will, obviously,
execute the entered Javascript. Similarly, in some lower versions of Internet Ex- plorer (IE6 and below) that URL format is allowed and will execute Javascript
so we have to take care of that as well.
For both the two before mentioned instances we might want to check that
the protocol is one we would allow. It would be better to create a white-list of
allowed protocols instead of creating a black-list of disallowed protocols. Simply select the protocols you want (e.g. http, https and ftp) and disallow all other.
Finally, this XSS cheatsheet might be useful to you. Both when learning
about XSS as well as testing that your application is secure.