Testing for Cross site scripting

[Up]
OWASP Testing Guide v2 Table of Contents

Brief Summary

Cross Site Scripting (CSS for short, but sometimes abbreviated as XSS) is one of the most common application level attacks that hackers use to sneak into web applications today. It should be stressed that although the vulnerability exists at the web site, at no time is the web site directly harmed

Description of the Issue

Cross site scripting is an attack on the privacy of clients of a particular web site which can lead to a total breach of security when customer details are stolen or manipulated. Unlike most attacks, which involve two parties – the attacker, and the web site, or the attacker and the victim client, the CSS attack involves three parties – the attacker, a client and the web site. The goal of the CSS attack is to steal the client cookies, or anyother sensitive information, which can identify the client with the web site. With the token of thelegitimate user at hand, the attacker can proceed to act as the user in his/her interaction with the site –specifically, impersonate the user.

Online message boards, web logs, guestbooks, and user forums where messages can be permanently stored also facilitate Cross-Site Scripting attacks. In these cases, an attacker can post a message to the board with a link to a seemingly harmless site, which subtly encodes a script that attacks the user once they click the link. Attackers can use a wide-range of encoding techniques to hide or obfuscate the malicious script and, in some cases, can avoid explicit use of the <Script> tag. Typically, XSS attacks involve malicious JavaScript, but it can also involve any type of executable active content. Although the types of attacks vary in sophistication, there is a generally reliable method to detect XSS vulnerabilities.

Black Box testing and example

---

One way to test for XSS vulnerabilities is to verify whether an application or web server will respond to requests containing simple scripts with an HTTP response that could be executed by a browser. For example, Sambar Server (version 5.3) is a popular freeware web server with known XSS vulnerabilities. Sending the server a request such as the following generates a response from the server that will be executed by a web browser:

/testcgi.exe?<SCRIPT>alert(“Cookie”+document.cookie)</SCRIPT>

The script is executed by the browser because the application generates an error message containing the original script, and the browser interprets the response as an executable script originating from the server. All web servers and web applications are potentially vulnerable to this type of misuse, and preventing such attacks is extremely difficult. Consider implementing the following recommendations if one or more XSS vulnerabilities have been detected in your application

---

References

Article on XSS holes http://www.perl.com/pub/a/2002/02/20/css.html

"CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests" http://www.cert.org/advisories/CA-2000-02.html

Whitepapers

Tools

---

OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents