Difference between revisions of "Talk:Testing for Cross site scripting"

Latest revision as of 17:42, 27 July 2007

(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.
• Consider converting JavaScript and HTML tags into alternate HTML encodings (such as “<” to “<>.
• 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.
For

example: " style="background:url(JavaScript:alert(Malicious Content));

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.