Tuesday, January 02, 2007

Gmail's CSRF Security Flaw, is OpenACS vulnerable to a CSRF attack ?

For those interested to read about Gmail's CSRF security flaw, click the title to go directly to the article over at Ajaxian.

Don't be misled, just because it's in the Ajaxian, doesn't mean that this is purely a problem with web applications that use Ajax. In fact, if I understand CSRF correctly, an out of the box OpenACS application that uses ad_form is possibly vulnerable. Well, except for the login form :-) Curious ? read on ....

What is CSRF ?

CSRF is an acronym for "cross site request forgery". Also known as "session riding", it describes a malicious exploit where a script takes advantage of an authenticated session to get information, like in Gmail's case, your contact list, but in other cases can be your personal or, worse, your financial information from the site that your browser is currently authenticated with.

How does it Work ?

The players involved are (A) you, the user, (B) the site with the malicious script and (C) the website where you are currently logged in or authenticated with. Examples of (C) are Gmail, your online banking website or an OpenACS web application.

The scenario would go something like this.

The user (A) logs in to (C) and stays logged in by checking "Remember me on this computer". On another window or tab, (A) goes to a website (B) with the malicious script. The script in (B) gets executed either from clicking a link or loading a page. The script from (B) will attempt to access (C) using the authenticated session and attempt to retrieve information like your contact list or other information.

Javascript can't do that ! Can it ?

Javascript is not suppose to be able to have access to cookies from other domains. Cookies are used to determine if a user is logged in to a site. They contain session information and other user specific information, hence, the browser imposes this cross domain limitation on javascript. In short, you can't use javascript to fake or manipulate cookies of other domains.

So this exploit will only work if the user (A) is logged in to (C) at the moment the script in (B) is executed.

Where did Gmail go wrong ?

In the case of Gmail, they were exposing a URL that returned JSON structured data that contained the contact list information. Hence you can actually put this url in script tags with the src pointing to this url. Like so


<script type="text/javascript" src="http://docs.google.com/data/contacts?out=js&show=ALL&psort=Affinity&callback=google&max=99999"></script<


While the browser prevents javascript from one domain to control a window in another domain, it will however allow you to specify a javascript source file from another domain.

I'm sure Gmail checks that the user is logged in before actually serving the javascript source file but after this check it has no way of knowing for sure that it was the user who requested it or a script from (B) a malicious website.

Is my OpenACS Web Application vulnerable ?

Unless your OpenACS application is running a web service or providing some sort of API, chances are its not.