Talk:Testing for Cross site scripting
(Meucci) NOTE: We can add this recommendations in the OWASP Guide. Are you agree?
The following general recommendations can help mitigate the risk associated with Cross-Site Scripting vulnerabilities. This is a complex problem area
so there is no one simple fix or solution:
- Ensure that your web application validates all forms, headers, cookie fields, hidden fields, and parameters, and converts scripts and script tags
to a non-executable form.
- Ensure that any executables on your server do not return scripts in executable form when passed scripts as malformed command parameters.
- If your site runs online forums or message boards, disallow the use of HTML tags and Scripting in these areas.
- Keep up with the latest security vulnerabilities and bugs for all production applications and servers.
- Update your production servers with the latest XSS vulnerabilities by downloading current patches, and perform frequent security audits on all
deployed applications. The root cause of Cross-Site Scripting is a failure to filter hazardous characters from web application input and output. The two most critical
programming practices you can institute to guard against Cross-Site Scripting are:
- Validate Input
- Encode output
Always filter data originating from outside your application by disallowing the use of special characters. Only display output to the browser that
has been sufficiently encoded. When possible, avoid simple character filters and write routines that validate user input against a set of allowed,
safe characters. Use regular expressions to confirm that data conforms to the allowed character set. This enhances application security and makes it
harder to bypass input validation routines. There are different tools you can use to validate and encode your data, depending upon your development environment. Your goal in remediating
Cross-Site Scripting attacks is to filter and encode all potentially dangerous characters so that the application does not return data that the
browser will interpret as executable. Any unescaped or unecoded data that is returned to the browser is a potential security risk. The following characters can be harmful and should be filtered whenever they appear in the application input or output. In output, you should
translate these characters to their HTML equivalents before returning data to the browser.
> < ( ) [ ] ' " ; : / |
PHP The following PHP functions help mitigate Cross-Site Scripting Vulnerabilities:
- Strip_tags() removes HTML and PHP scripting tags from a string.
- Utf8_decode() converts UTF-8 encoding to single byte ASCII characters. Decoding Unicode input prior to filtering it can help you detect
attacks that the attacker has obfuscated with Unicode encoding.
- Htmlspecialcharacters() turns characters such as &,>,<,” into their HTML equivalents. Converting special characters to HTML prevents
them from being executed within browsers when outputted by an application.
- Strtr() filters any characters you specify. Make sure to filter “; : ( )” characters so that attackers cannot craft strings that generate
alerts. Many XSS attacks are possible without the use of HTML characters, so filtering and encoding parentheses mitigates these attacks.
ASP.NET With ASP.NET, you can use the following functions to help prevent Cross-Site Scripting:
- Constrain input submitted via server controls by using ASP.NET validater controls, such as RegularExpressionValidator, RangeValidator,
and System.Text.RegularExpression.Regex. Using these methods as server-side controls to limit data input to only allowable character sequences
by validating input type, length, format, and character range.
- Use the HtmlUtility.HtmlEncode method to encode data if it originates from either a user or from a database. HtmlEncode replaces special
characters with their HTML equivalents, thus preventing the output from being executable in the browser. Use HtmlUtility.UrlEncode when writing URLs
that may have originated from user input or stored database information.
- Use the HTTPOnly cookie option for added protection.
- As a best practice, you should use regular expressions to constrain input to known safe characters. Do not rely solely on ASP.NET validateRequest,
but use it in addition to your other input validation and encoding mechanisms.