Monday, February 25, 2008

Leave Cookies to the Keebler Elves

If you don't know what CSRF is, you can read about it here.

I was talking to some developers today about using tokens and requiring passwords on forms to prevent CSRF. Then my friend Matt asked why can't we just stop using cookies?

If an application doesn't rely on a browser automatically sending cookies for session management, CSRF will be a non issue. Of course, this means that the developers have to handle session management with additional code (those poor souls!). Instead of the browser automatically sending the cookies with each request, the developers need to make sure any link or form action has the session ID in it. We looked at Tomcat, and to some extent, it has the ability to automatically append session identifiers to some URLs (I need to research this more).

Having the session ID in the query string does introduce other risks, such as making it visible in logs on the web server and any intermediate proxy. Right now, I think the benefit of zero CSRF outweighs those risks.

HTTP wasn't designed to be maintain state. Cookies were an after thought, once people realized they needed a way to group multiple requests together into a logical "session".

Unfortunately, Web2.0 gives us much more code executing on the client, all of which relies on the web browser sending cookies with each outgoing request (assuming the receiving code on the app server actually verifies the request are part of a valid session). That said, I don't think we'll see any mass exodus from cookies any time soon.

Updated 2:26PM EST 2/25/2008
I totally forgot about session hijacking attacks, which are a good reason not to rely on session identifiers being sent in URL query-strings. This is where attackers forge links with session ID's in them and trick users into clicking on them and logging in. These attacks could lead to badness worse than that of CSRF.

Updated 9:24PM EST 2/25/2008
Doh! I should have read my last post. Session ID's in the URL are also vulnerable to referer leakage!

(That's what happens when I get to eager to press "publish" and head out to lunch!)

No comments: