What are cross site scripting attacks?

Cross-site scripting (XSS) bugs are a form of security defect unique to web-based applications that allow user data tied to the vulnerable web server's domain, usually held in cookies, to be disclosed to a malicious third party. Hence the term "cross-site": the cookie is transferred from a client computer accessing a valid, but vulnerable, web-server site to a site of the attacker's bidding. At least, this is the most common type of attack using XSS.

Any language or technology used to build a web site; for example PHP, Active Server Pages (ASP), C#, VB.Net, ASP.NET, J2EE (JSP, Servlets), Perl, and Common Gateway Interface (CGI) can be affected by this attack.

The sin is straightforward: a web application takes some input from a user, perhaps from a query string, fails to validate the input, and echoes that input directly in a web page. It's really that simple! Because the web server is echoing input, the input might be a script language, such as JavaScript, and this is echoed and interpreted in the destination browser.

As you can see, this is a classic input trust issue. The web application is expecting some text, a name for example, in a querystring, but the bad guy provides something the web application developer never expected.

An XSS attack works this way:

1. The attacker identifies a web site that has one or more XSS bugs—for example, a web site that echoes the contents of a query string.
2. The attacker crafts a special URL that includes a malformed and malicious query string containing HTML and script, such as JavaScript.
3. The attacker finds a victim, and gets the victim to click a link that includes the malformed query string. This could be simply a link on another web page, or a link in an HTML e-mail.
4. The victim clicks the links and the victim's browser makes a GET request to the vulnerable server, passing the malicious querystring.
5. The vulnerable server echoes the malicious querystring back to the victim's browser, and the browser executes the JavaScript embedded in the response.

Because the code is running in the context of the vulnerable web server, it can access the victim's cookie tied to the vulnerable server's domain. The code can also access the Document Object Model (DOM) and modify any element within it; for example, the exploit code could tweak all the links to point to porn sites. Now when the victim clicks on any link, he is whisked off to some location in cyberspace he wished he hadn't gone to.
The output does not need to be visible to lead to an XSS bug; any kind of echo will suffice. For example, the web server might echo the input as an argument in a valid JavaScript block in the web page, or perhaps the data is the name of an image file in an IMG tag.

Be wary of blog or product review/feedback web applications because this type of application must read arbitrary HTML input from a user (or attacker) and then echo said text for all to read. In an insecure application, this leads to XSS attacks.