atom feed7 messages in net.java.dev.dwr.users[dwr-user] HttpOnly
FromSent OnAttachments
Joe WalkerDec 11, 2008 2:12 pm 
Chris HollandDec 11, 2008 2:41 pm 
Mike WilsonDec 12, 2008 1:34 am 
Joe WalkerDec 15, 2008 10:22 am 
Mike WilsonDec 16, 2008 11:41 am 
Joe WalkerDec 16, 2008 4:01 pm 
Mike WilsonDec 17, 2008 12:49 am 
Subject:[dwr-user] HttpOnly
From:Joe Walker (jo@getahead.org)
Date:Dec 11, 2008 2:12:32 pm
List:net.java.dev.dwr.users

I'm sending this to DWR-users and DWR-security, we should probably direct follow-up messages to use@dwr.dev.java.net only.

I can see HttpOnly causing us some *serious* problems.

The problem: There is a chance that Servlet 3.0 is going to encourage app-servers to HttpOnly the JSESSIONID cookie (and even if it doesn't, there is a decent chance that they will anyway)

HttpOnly on JSESSIONID breaks our CSRF protection. So I think it's likely that we'll be inundated with calls questioning why DWR has broken. Our response 'turn off HttpOnly' will be met with horror by many security departments that think we're breaking security.

My view is that at best, HttpOnly only slows an attacker down, but doesn't really fix any holes. Also it confuses people into thinking they are safer from something when they're not really. In addition it breaks double-submit. Hence I'm not keen on it. It would be good to know if anyone has a strong opinion that it's a Good Thing.

It would be good if we could come up with some alternative solution, so we didn't need an HttpOnly free JSESSIONID cookie. Even if I can convince the servlet spec not to recommend it's use, some app-server vendor will implement it, I'm sure.

The problem is that we need to get a token to the DWR JavaScript *before* the first DWR call made from a page. JSESSIONID was a great way to do that. I've thought of 3 alternate solutions: 1. The best way that I can think of (so far) is to force everyone to use a DwrServletFilter to wrap all requests, and then spray extra DWR cookies everywhere. Not nice, but probably workable. 2. Force everyone to use JSP (or similar non-HTML solution) and to have a token that we push into the HttpSession and the page. DWR reads the token in the page, and sends it with every request. We then check any pages that have an HttpSession to ensure that the session contains a token that matches what DWR has sent with the page. 3. DWR could maintain it's own security context totally aside from the Servlet based security, but that would mean that HttpSession was not trustable for DWR calls - Not a good solution.

Can anyone think of any better solutions?

Joe.