Thursday, May 19, 2011

Socially-Engineered XSS Attacks

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.

It turns out, however, that there’s a fourth type of XSS attack: Socially-engineered XSS. In a socially-engineered XSS attack, the user is tricked into running an attacker’s JavaScript code in the context of the victim site. Even if a site follows best-practices to block XSS Types 0, 1 and 2, they may still be vulnerable to Socially Engineered XSS attacks.

Such attacks work in the same way as most socially-engineered attacks, by attacking the weakest link in browser security—the user’s trust. The attacks request that the user perform a series of operations (often using keyboard key combinations) that result in a JavaScript URL being entered in the address bar and invoked. JavaScript URIs entered in this way execute in the context of the currently loaded page. Users are tricked into following these instructions with the promise of some reward (e.g. free “points” for games, “secret” information about other users, etc).


1 comment:

Mathias said...

Nice write, browsers should perhaps show a warning whenever trying to use the javascript protocol handler.

Also, chrome can detect reflected XSS attack aswell nowadays, by refusing to execute script which source can be found within the request.

Another type of "Social engineering XSS" would be with the use of the HTML5 Drag and Drop exploit, which relie on that the user will drag/drop a HTML element on the page.