Requires Membership to View
To gain access to this and all member only content, please provide the following information:
By submitting your registration information to SearchSecurityChannel.com you agree to receive email communications from the TechTarget network of sites, and/or third party content providers that have relationships with TechTarget, based on your topic interests and activity, including updates on new content, event notifications, new site launches and market research surveys. Please verify all information and selections above. You may unsubscribe at any time from one or more of the services you have selected by editing your profile, unsubscribing via email or by contacting us here
- Your use of SearchSecurityChannel.com is governed by our Terms of Use
- We designed our Privacy Policy to provide you with important disclosures about how we collect and use your registration and other information. We encourage you to read the Privacy Policy, and to use it to help make informed decisions.
- If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States.
Dynamic Web sites suffer from a threat that static Web sites don't, called cross-site scripting (XSS). An XSS vulnerability is created by the failure of a Web-based application to validate user-supplied input before returning it to the client system.
XSS attacks usually come in the form of embedded JavaScript; however, any embedded active content is a potential source of danger, including ActiveX, VBscript and Flash.
The XSS flaw exploit can cause serious problems -- including accessing the user's session cookie -- thereby allowing an attacker to hijack the session and take over the account. It can also install malware, redirect the browser and disclose sensitive information.
XSS has been around for quite awhile. A simple code example of an XSS vulnerability is as follows:
- Sample web request code could be:
- The HTML returned by the server after making this request includes the code:
"<h1>Section Title</h1>" - The user input passed to the "title" query string parameter was probably placed in a string variable and inserted by the Web application into an <h1> tag.
By providing the input the attacker controls the HTML. If the site is not filtering input server-side, an attacker could inject code by breaking out of the <h1> tag, such as:
Therefore, the HTML output from the attacker's input would look like:
XSS flaws can be difficult to identify and remove from a web application. The best way to find flaws is to perform a security review of the code and search for all places where input from an HTTP request could possibly make its way into the HTML output. Note that a variety of different HTML tags can be used to transmit a malicious JavaScript.
As far as testing for XSS vulnerabilities, automated scripts can be used, but the testing is most typically performed manually. Microsoft has a good piece on how to test for XSS using various tools and a reporting methodology.
Nessus, Nikto and some other available tools can help scan a website for these flaws, but can only scratch the surface. If one part of a website is vulnerable, there is a high likelihood that there are other problems as well.
The best way to protect a Web application from XSS attacks is ensure that your application performs validation of all headers, cookies, query strings, form fields, and hidden fields (i.e., all parameters) against a rigorous specification of what should be allowed.
To learn more about penetration testing, visit the Penetration Testing Project Guide.
This was first published in April 2007