Share via

Socially-Engineered XSS Attacks

  • Article

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).

Here’s a screenshot of an attack that I encountered yesterday:

image

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.

In Internet Explorer 9, we’ve added a simple protection that significantly raises the bar against this type of attack. Specifically, IE9 will remove the “JavaScript:” prefix[1] from any string that is pasted into the address bar. So, in order for a user to fall victim to a self-inflicted attack of this nature, they have to be persuaded to copy/paste the attack code in the address bar, then go to the beginning of the URL, type “javascript:” and hit enter. This additional step adds complexity (and suspicion), and our early data that indicates that IE9 users are much less likely to fall victim to such attacks.

Web-elites who would recognize this attack immediately (e.g. many readers of this blog’s small readership) might think this new protection cumbersome, since they can no longer trivially paste things like “javascript:alert(document.cookie);” into the address bar to see the current page’s cookies. However, IE will still allow pasting of the code itself, so you need only type the JavaScript protocol prefix. For script operations you undertake frequently, you can store the code in a simple Bookmarklet and simply invoke that rather than trying to paste in the address bar. Internet Explorer 9 includes several improvements for bookmarklets. In IE9, a bookmarklet may now contain up to 5kb of JavaScript (previously, the limit was 2083 characters), and bookmarklets may again be dragged from a webpage into the Favorites bar, triggering the following prompt:

image

-Eric Lawrence

[1] 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.

Comments

  • Anonymous
    May 19, 2011
    Won't the attack simply change from "Ctrl+C, Ctrl+L, Ctrl+V, Enter" to "Ctrl+C, Ctrl+L, Ctrl+V, Home, J, A, V, A, S, C, R, I, P, T, :, Enter"? If someone is willing to follow the first set of steps, why won't they be willing to follow some slightly more elaborate steps?

  • Anonymous
    May 19, 2011
    @Dawson: I'm sure that attackers will eventually try that. With every additional step, however, the success rate of the attack drops off, and some users are likely to be more suspicious when they start typing the word "script". Hence, as I mentioned, the data we're seeing vis-a-vis the relative scarcity of IE9 victims. Additionally, in the near term, since only IE9 has this protection, the attackers have to have two sets of instructions; anything that requires the user to know what version of the browser they're using eliminates a key part of the victim demographic. (Browser detection is often beyond the capabilities of the attackers, since if they already had scripting permissions, they wouldn't need to undertake the attack).

  • Anonymous
    May 19, 2011
    I can see how this would be a reasonable solution, but, as someone who pastes javascript into his address bar constantly, this feature would really bother me. Add an option to disable this feature - PLEASE! [EricLaw]: @Jim: There's no option for this. Thanks for the feedback.

  • Anonymous
    May 19, 2011
    @Jim: If you're doing a lot of JS debugging, why not use the F12 window? The "Script" tab has a nice interpreter area where you can stick JavaScript code without even having to use the javascript:// protocol handler prefix! BTW, this will probably become the next vector of attack for those wonderful social engineering types. :-(

  • Anonymous
    May 19, 2011
    This sounds like a sensible change, @EricLaw.  However, the vast majority of users will never want or need to run any javascript from the address bar at all.  So why not completely disable the running of javascript from the address bar - regardless of whether the user enters the prefix - then have an option for advanced users to re-enable it?

  • Anonymous
    May 20, 2011
    The comment has been removed

  • Anonymous
    May 20, 2011
    The comment has been removed