Archive for the XSS Category

When Microsoft unveiled its IE 8's "XSS filters", almost one year ago, we could notice how, despite their impressive resemblance to NoScript's anti-XSS protection, they were quite limited in comparison.

One of the limitations was their ability to mitigate a subset of reflective (AKA type 1) XSS vulnerabilities only, leaving them totally useless against DOM-based (AKA type 0) XSS attacks which, instead, are effectively defeated by NoScript.

Today I noticed via that such a DOM-based XSS attack is currently possible against Paypal and Ebay, no less, allowing the attacker to steal authentication info and other sensitive data, or even perform financial transactions on the behalf of the victim.

Even more interesting, modern browsers* except IE properly encode request URLs before sending them on the wire, but exploitation of this specific Paypal vulnerability requires the "double quotes" character to pass through with no encoding: therefore, while the vast majority of XSS exploits are cross-browser, this one affects exclusively IE**. Embrace and XSStend?

  1. * Latest versions of Firefox, Safari, Opera and Chrome.
  2. ** Variants could affect any browser, since IE's encoding bug is generally not required for DOM-based XSS. Firefox users can protect themselves by using NoScript, even in the permissive and not recommended "Allow Scripts Globally" mode.

Sick BirdEverybody heard the tweets: after several other security issues, including "exotic" ones like Clickjacking or JSON hijacking, Twitter is in serious troubles again, this time with an old-school XSS worm which quickly managed to infect many users profiles and is still spreading in multiple variants.

This plague is the brainchild of a 17 years old named Mikeyy, who created it as a publicity stunt to promote his own Twitter clone, A good technical description of its rather simple inner workings has been kindly provided by Damon Cortesi. As you can see, unless the doman is allowed to run JavaScript (very unlikely for NoScript users) you're immune from infection.

This worm having been active so long is quite a surprise to me, since the exploited vulnerability (missing output encoding on users' profile web page URL) requires less than one minute to be fixed, if you know what you're doing. The existence of a mildly obfuscated version authorizes a scary suspect: have Twitter guys just been trying to block the original strain by signature, rather than fixing their website error? This is would be ridiculous*, since any script kiddie can create his own slightly modified version for fun or profit (and is probably doing that). And while the initial code just logs your session cookie on a remote server (which is already bad enough) and replicates itself as spam, nothing restrains a more malicious attacker from taking over your account with all its profile data right away.

The morale of this story? Never tweet without NoScript.

* Update

Ridicolous, but apparently true: in Twitter's first hand account of the countermeasures taken over the weekend, there's a lot of "cleaning up and locking down profiles", but nothing about fixing the website's bugs which allow infections like this to be spread.

About one year ago, a Firefox 3 beta appeared to eliminate a long standing XSS hazard, by preventing 3rd party XBL from being loaded and executed in a content document.
This enhancement, while going in the right direction, received some skeptical comments because at the same time the ability of specifying inline XBL bindings using data: URIs had been introduced, opening new exploitation venues. The data: XBL thing was obviously an oversight: in fact, Firefox 3 stable didn't allow it anymore, except "from chrome code (in other words, from the application or an extension)”.
However these mitigations had been anticipated and surpassed by a configurable cross-site XBL protection feature introduced a few months before by NoScript, whose default settings were more restrictive and effective than the new browser built-in XBL policy, even when Firefox 3.0 stable seemed to get it right. Seemed.

According to the MDC documentation,

The normal same-origin policy is used for web sites; they can only link to XBL files on the same domain, or within the chrome.

This statement tricked most readers (including myself, some sla.ckers and probably even hardcore Mozilla hackers like Jonas Sicking) into believing that everything was fine and dandy. Except that we've just learned (the painful way) that a more precise formulation describing what actually happens should have been:

Web pages and stylesheet can only link to XBL files in the same domain as the linking file itself.

In other words, if I open a web page including a stylesheet from site, which in turn links a XBL file from the same domain, Firefox 3 lets everything work smoothly (the stylesheet and the XBL being same-origin), with the net result that XBL scripts from are allowed to run on (the very "bad thing" which Firefox 3 was supposed to prevent).

I must admit that if I was not committed to supporting Firefox 2, after reading the misleading documentation above I would have likely dropped NoScript's own cross-site XBL protection, which actually blocks any cross-site XBL (i.e. XBL from a domain different than the loading document) except from chrome: the way the documentation falsely seemed to imply and the only effective way from a XSS mitigation standpoint. Blessed be FSM the Merciful for inspiring backward compatibility concerns in my unworthy soul ;)

Unfortunately for non-believers, "bad guys" noticed this theory/practice discrepancy (or, more likely, just empirically realized that some old malicious XBL code still worked against Firefox 3) and are exploiting it in the wild, together with a similar well known Microsoft proprietary "feature" (dynamic properties) allowing JavaScript to be run from stylesheets in IE.

Specifically, The Register's Dan Goodin wrote about an eBay scam (originally reported by Cefn Hoile) based on this XSS weakness. Of course, rather than browser flaws, there's a fundamentally broken web design choice here to blame: allowing unfiltered user-provided stylesheets to be embedded in "trusted" content is very dangerous independently from JavaScript execution, because an attacker could modify the appearance of the page in malicious ways, e.g. for Clickjacking purposes, or even access some page content (password fields!). But on the other hand, preventing stylesheets inclusions from executing 3rd party malicious scripts (like Opera, Safari and Chrome do) actually reduces the attack surface, which was the apparent intention of the original Firefox 3 XBL policy change.

If Microsoft, according to Goodin, won't do anything about this issue, Mozilla developers are already working to a fix. In the meanwhile you can rely on NoScript, one step (more than one year, actually) ahead as usual...

During the past weeks I've started a new project called ABE, sponsored by the NLnet Foundation and meant to provide CSRF countermeasures configurable on the client side, the server side or both.

As you probably know, the NoScript browser extension improves web client security by applying a Default Deny policy to JavaScript, Java, Flash and other active content and providing users with an one-click interface to easily whitelist sites they trust for active content execution. It also implements the most effective Cross-Site Scripting (XSS) filters available on the client side, covering Type-0 and Type-1 XSS attacks; ClearClick, the only specific browser countermeasure currently available against ClickJacking/UI redressing attacks, and many other security enhancements, including a limited form of protection against Cross-Site Request Forgery (CSRF) attacks: POST requests from non-whitelisted (unknown or untrusted) sites are stripped out of their payload and turned into idempotent GET requests.

Many of the threats NoScript is currently capable of handling, such as XSS, CSRF or ClickJacking, have one common evil root: lack of proper isolation at the web application level. Since the web has not been originally conceived as an application platform, it misses some key features required for ensuring application security. Actually, it cannot even define what a "web application" is, or declare its boundaries especially if they span across multiple domains, a scenario becoming more common and common in these "mashups" and "social media" days.

The idea behind the Application Boundaries Enforcer (ABE) module is hardening the web application oriented protections already provided by NoScript, by developing a firewall-like component running inside the browser. It will be specialized in defining and guarding the boundaries of each sensitive web application relevant to the user (e.g. webmail, online banking and so on), according to policies defined either by the user himself, or by the web developer/administrator, or by a trusted 3rd party.

ABE rules, whose syntax is defined in this specification (pdf), are quite simple and intuitive, especially if you ever looked at a firewall policy file:

# This one defines normal application behavior, allowing hyperlinking
# but not cross-site POST requests altering app status
# Additionally, pages can be embedded as subdocuments only by documents from
# the same domain (this prevents ClickJacking/UI redressing attacks)
Site *
Accept POST, SUB from SELF
Accept GET

# This one guards logout, which is foolish enough to accept GET and
# therefore we need to guard against trivial CSRF (e.g. via <img>)
Accept GET POST from SELF

# This one guards the local network, like LocalRodeo
# LOCAL is a placeholder which matches all the LAN
# subnets (possibly configurable) and localhost
Accept from LOCAL

# This one strips off any authentication data
# (Auth and Cookie headers) from requests outside the
# application domains, like RequestRodeo
Site *
Accept ALL from *

Living inside the browser, the ABE component can take advantage of its privileged placement for enforcing web application boundaries, because it always knows the real origin of each HTTP request, rather than a possibly missing or forged (even for privacy reasons) HTTP Referer header, and can learn from user's feedback.
Rules for the most popular web applications will be made downloadable and/or available via automatic updates for opt-in subscribers, and UI front-ends will be provided to edit them manually or through a transparent auto-learning process, while browsing. Additionally, web developers or administrator will be able to declare policies for their own web applications: ABE will honor them, unless they conflict with more restrictive user-defined rules.
As soon as browser support for the Origin HTTP header becomes widespread and reliable, an external version of ABE might be developed as a filtering proxy.

An initial implementation will be released during the 1st quarter of 2009 as a NoScript module.
I already collected precious feedback from security researchers like Arshan "Anti-Samy" Dabirsiaghi, Ivan Ristic of ModSecurity fame, Sirdarckcat and others.
More opinions and suggestions about rules design and features are very welcome.

Tasmanian Devil

Dec 6, 7:25 PM, IM

Arshan* to me:

noscript saved me today, literally, from none other than the infamous samy

Dec 7, 3:16 AM, Email

From: samy**
To: Giorgio Maone
Subject: giorgio, i'm mad at you


I am mad at you. My friend, Arshan Dabirsiaghi, whom I will refer to from now on only as "the persian", was viewing a web page. The web page in question had what the kids these days are calling, "XSS". The XSS was malicious. As malicious as a chicken nugget from McDonalds. Worse, maybe.

But you see, my friend, the persian, was not affected. Why is this you ask? I asked him the same thing. He told me that I should blame you for him being safe. I don't think he literally meant come to you and blame you, but you see, I am coming to you anyway and blaming you. He was running this extension (of his penis) known only as NoScript, or what I will refer to as "the devil's plugin". And for this, I am angry. Angry at the plugin, the use of it, and by extension the author. You, sir, you. That is all. All I can do now is attempt to correct your rights.

Good morrow to you, fine sir.

Your frienemy,

*Arshan Dabirsiaghi of Aspect Security and OWASP, lead developer of the OWASP Anti-Samy Project.
** The infamous Samy, author of the eponymous MySpace XSS Worm.


The original Samy's message contained a slightly antizionist joke about Arshan's supposed descent. I edited it out even if Samy gave his consent for verbatim publishing, because Guanxi made me notice that some people may find it offensive rather than parodic, or even worse read it as an implicit justification for antisemitism.

Update 2

I re-edited the original message after Samy suggested me a way to make it become, "all of the sudden accurate rather than offensive".

Bad Behavior has blocked 725 access attempts in the last 7 days.