When the IE team talks about Cross-Site-Scripting (XSS) attacks, we’ve usually grouped them into three categories
- Type 0: DOM-based XSS
- Type 1: “Reflected” XSS
- Type 2: Persistent/Stored XSS
DOM-APIs like toStaticHTML enable pages to protect themselves against Type 0 attacks. The Internet Explorer XSS Filter can block Type 1 attacks by detecting reflected script and neutering it. Servers can protect themselves against Type 2 attacks using the Anti-XSS library to sanitize stored data.
Here’s a screenshot of an attack that I encountered yesterday:
Now, I’ve seen far slicker versions that mask themselves far more cleverly, such that the script isn’t ever seen. In the manner of an old game cheat, the unknowing user presses CTRL+C, CTRL+L, CTRL+V, ENTER, and the bad guy’s code runs.
These attacks often target popular social networks, and their first action upon running is to spread to all of the user’s contacts, leading to an extremely rapid infection across the social graph. Thousands of users can fall for an attack like this in a few hours. After arranging to spread to the user’s contacts, these attacks typically engage in spamming malware-distributing links or other activities that generate revenue for the bad guys. Because the script runs in the security context of the victim page, any information on the current site may be available for perusal by the attacker.
 Internet Explorer will actually strip out any script-prefix, including misspelled strings that might otherwise be autocorrected into a script prefix. Also, if there’s existing content in the address bar (e.g. a j) if adding pasted content (e.g. avascript) will create a script prefix, it will still be removed.