Below is an example of active\client XSS that I ran into sometime ago. Active\client XSS refers to the situation when the user themselves does something to inject malicious code or html into a website that compromises themselves. You are probably thinking why on earth would they do that.
Well below is a good example of how a weakness in the design of a web application can be used. Once I had a great idea to reuse an error page for simple errors. Rather than have lots of error pages, why don’t I just pass the error in the query string and then display it on screen. If the values are encoded when it is displayed then it is not possible to inject scripts so everything should be ok.
So the if I called the URL http://www.mysite.com/errorpage=Your id was not recognised
This would display an error page something like below
Your id was not recognised.
A security review pointed out someone could be sent a link in an email
In response MySite.com would display a page with
This site has moved to http://www.mysite1.com
The user goes to the bogus mysite1.com, which presents a password screen, the user enters their username & password and bingo the username and password are leaked – oops.
In this case the url contains the malicious text and the user is injecting the problem themselves by opening the link, thus active XSS. If the output was not encoded then a hacker could go further and maybe inject a call to a script into the URL. The script could alter the screen to show a fake logon screen.
If I wanted to have a single page to display errors then I should have passed a code and then used the code to look up the message that should be displayed. This effectively whitelists the input and output.
Search screens are a target for this type of attack as they often display the search term on the screen. If you have a search result screen that redisplays the input make sure you encode the term before displaying it and maybe limit the term’s size on input and output. You could perhaps restrict the input to A-Z, a-z, 0-9 and space.