.NET Framework 2.0 Security Inspection Questions - Cross-Site Scripting

From Guidance Share

Jump to: navigation, search

- J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Jason Taylor, Rudolph Araujo


Cross-Site Scripting Vulnerability and Implications

Vulnerability

Implications

Unvalidated and untrusted input in the HTML output stream

Cross-site scripting can allow an attacker to execute a malicious script or steal a user's session and/or cookies.


Code is vulnerable to cross-site scripting attacks wherever it uses input parameters in the output HTML stream returned to the client. Even before you conduct a code review, you can run a simple test to determine if your application is vulnerable. Search for pages where user input information is sent back to the browser.

To perform this test, type text, such as XYZ, in form fields and test the output. If the browser displays XYZ or if you see XYZ when you view the HTML source, then your Web application is vulnerable to cross-site scripting. If you want to perform a more dynamic test, inject <script>alert('hello');</script>. This technique might not work in all cases because it depends on how the input is used to generate the output.

The following questions can help you to identify vulnerable areas:

  • Does the code echo user input or URL parameters back to a Web page?
  • Does the code persist user input or URL parameters to a data store that could later be displayed on a Web page?


Does the code echo user input or URL parameters back to a Web page?

If you include user input or URL parameters in the HTML output stream, you might be vulnerable to cross-site scripting. Make sure that the code validates input and that it uses HtmlEncode or UrlEncode to validate output. Even if a malicious user cannot use your application's UI to access URL parameters, the attacker still may be able to tamper with them.

Reflective cross-site scripting is less dangerous than persistent cross-site scripting due to its transitory nature.

The application should not contain code similar to the following example.

Response.Write( Request.Form["name"] );
 

Instead, the application should contain code similar to the following.

Response.Write( HttpUtility.HtmlEncode( Request.Form["name"] ) );


Does the code persist user input or URL parameters to a data store that could later be displayed on a Web page?

If the code uses data binding or explicit database access to put user input or URL parameters in a persistent data store and then later includes this data in the HTML output stream, the application could be vulnerable to cross-site scripting. Check that the application uses HtmlEncode or UrlEncode to validate input and encode output. Pay particular attention to areas of the application that permit users to modify configuration or personalization settings. Also pay attention to persistent free-form user input, such as message boards, forums, discussions, and Web postings. Even if an attacker cannot use the application's UI to access URL parameters, a malicious user might still be able to tamper with them.

Persistent cross-site scripting is more dangerous than reflective cross-site scripting.

Personal tools