hackademix.net

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 3^rd 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 *.somesite.com
Accept POST, SUB from SELF https://secure.somesite.com
Accept GET
Deny

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

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

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

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 1^st 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.

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

Giorgio,

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,
samy

Update

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

I just stumbled upon a post by Lori MacVittie, Why it’s so hard to secure JavaScript.
I found it interesting because it voices the (frustrated) opinion of an important Web Application Firewall vendor, F5, about something I’ve been reasoning for some years :)
She essentially admits scripting languages are such a mess to secure at the semantic level («Hey Giorgio, why doesn’t NoScript just strip out malicious scripts and leave the rest my page alone?»), especially from an external node (like a firewall) which does not actually parse the code:

I am not aware of any security solution that currently parses out JavaScript before it’s delivered to the client. If there are any out there, I’d love to hear about them.

Well, WebCleaner comes to mind.
Also NoScript’s Anti-XSS filters actually parse cross-site request fragments through SpiderMonkey, mainly to reduce false positives by acting on syntactically valid JS only.

But she obviously means something different: a device placed outside the browser, parsing JavaScript and performing sandboxed behavioral analysis.
The latter is the true challenge here, but building such a toy might be not impossible, especially since the best JavaScript implementations out there, Mozilla’s SpiderMonkey/TraceMonkey and Google’s V8 are open-source and embeddable. However, performance penalties aside (most of the scripts should be parsed and possibly compiled and executed at least twice), you would loose a very important decision factor: browser context, i.e. DOM, cookies, authenticated sessions, navigation history and so on.
Unless they imagine to stuff a “twin” of your browser inside your firewall, sort of a proxy based on Gecko+SpiderMonkey or WebKit+V8 and acting as a guinea pig just before the “real” navigation happens…
But for the time being,

That’s why browser add-ons like NoScript are so popular. JavaScript security today is binary: allow or deny. Period. There’s no real in between. There is no JavaScript proxy that parses and rejects malicious script, no solution that proactively scans JavaScript for code-based exploits, no external answer to the problem. That means we have to rely on the browser developers to not only write a good browser with all the bells and whistles we like, but for security, as well.

As you probably have heard, security expert Petko D. Petkov (pdp), founder of GNUCITIZEN, had his GMail account violated and raided.
He told me he did not believe it had been a classic man in the middle attack, as many of us speculated during the past days, and interviewed by Dan Goodin he blamed XSS:

In an email exchange, Petkov said he suspected his Gmail account was accessed through a cross-site scripting (XSS) flaw.

Perhaps, but that doesn’t make sense to us. XSS exploits typically allow you to enter restricted parts of a website without the benefit of a password. Whoever broke into Petkov’s account was able to archive an entire email spool into an mbox file. Without knowing his password, the attackers most likely would have had to archive all 2GB message by message.

It makes sense to me, though (even if I still bet on a MITM, since GMail has been secured against cookie leakages side-tracking HTTPS only very recently): if you combine any XSS vulnerability with the very handy automatic password completion offered by modern browsers, stealing credentials becomes absolutely trivial.

However, if Petko is right, a certain comment of his about NoScript, posted under an article about GMail attacks (!) almost one year ago, sounds totally ironic now ;)

An email I received yesterday night:

Hi,

I’ve been using NoScript with Firefox for a while (recommended by SANS), and today it paid off bigtime.
I got to work, started Firefox, and went to our homepage.
NoScript complained and I checked out the complaint at the bottom of the page. Our webpage had a link on it to sdo.1000mg.cn.
I started looking and found that we had the SQL injection attack currently featured at SANS:

http://isc.sans.org/diary.html?storyid=4844

NoScript found it first! You are a hero! Thanks.

Jeff E.
[Anonymized US Educational Site]

Then a quote from Ryan Naraine’s Talking Firefox security with Mozilla’s Window Snyder:

There are discussions happening internally at Mozilla around adding NoScript functionality into the core browser.
“It’s a conversation we’re having. I’d love to see it in there.”

Oh Window, why didn’t you tell me these sweet words when we were face to face in the romantic and adventurous land of Whistler?
I guess it’s destiny, even Steve Ballmer had been too shy to declare his love ;)