A two-minutes post on fixing Cross site scripting issues
Hey programmers, this is simply a short and small recommendation, generic and not language-dependent. Please take two minutes or less to go through this post if you are new to the world of cross site scripting and you’re in the process of learning how to code securely.
It is critical that you don’t use a single encoding function in a find and replace manner. Some websites will blindly recommend programmers to use HTML encoding functions (i.e.: Server.HtmlEncode in ASP) for encoding on output, however, HTML encoding can only do some good on specific cases. It is extremely important that you understand the context where the vulnerability is taking place in order to understand what characters you need to encode and the way the characters need to be encoded.
For example, HTML encoding will usually just encode a small set of 4 characters being < > & ” into their HTML entities (< > & “) and using it on the following example will do absolutely nothing to fix the issue that exists in this PHP line:
<input value=’<?=dynamic_dangerous_variable?>’ type=”text” id=name>
If you are wondering why, then look at the characters that are enclosing the contents of the value attribute and refer back to the 4 characters the HTML encoding function encoded. Right, the function does not take care of encoding single quotes, therefore the issue still exists. An attacker could easily use single quotes to escape from the value attribute and either continue writing attributes for the input tag (such as onclick, onmouseover, …) or, if the encoding function allows it (which is not the case here) close the input tag and continue writing the malicious payload.
Strong encoding libraries such as Reform, the multi-language encoding library originally developed by Michael Eddington and now adopted by the OWASP project provide several sets of encoding functions to be used in different contexts.
The Reform library is available at the OWASP encoding project (http://www.owasp.org/index.php/Category:OWASP_Encoding_Project)
Another thing to have in mind is NOT to opt for generic filtering layers instead. Take some more time and perform encoding wherever needed, that is the right thing to do. Filtering layers could turn out strong but strong filtering layers mean several headaches. Why? If you look around, you will find that Cross site scripting attacks have evolved incredibly ever since and so have the techniques used to disguise Cross site scripting attacks.
A full listing of the different techniques used to disguise XSS attacks can be found at the Cross Site Scripting Cheat Sheet available at http://ha.ckers.org/xss.html (it goes offline every now and then, so be patient).
Hence if what you want to do is ‘filter all malicious characters’ you will end up filtering a really wide set of characters that you will most likely need for your application to run.
Should I have time and the will, you will soon find another post with regards to different techniques that exist in order to bypass filtering layers. You may want to test them on your own layers and see what happens 
Finally, you may want to consider avoiding any encoding on situations where the dynamic data being displayed to the browser is a URL. It is usually very easy to break functionality (break the url for instance) and that is something you definitely do not want to happen. You might fix the XSS issue but you will end up having a problem in QA. Therefore you can either validate the Url using a regex or if the dynamic portion of the Url is the querystring, encoding the querystring values using some kind of a UrlEncode method.
.-