Way back in February of this year, the company I work for made a very simple request of BEA. We requested that they add the ability to set the HttpOnly flag on the JSESSIONID cookie created by the server. In part, this would save security conscious developers time in that they would not have to go through the practice of creating a special Filter to programmatically set this attribute. More importantly, this would decrease the overall attack surface of any web application by mitigating such attacks as session hijacking.
Well, as you may have guessed by now, they have made absolutely no progress on this. Why? It is not that hard! They already have support for the Secure flag (here and here)! How hard could it be to copy this logic, rename it from cookie-secure to cookie-httpOnly and instead of adding the string secure add the string HttpOnly? Maybe four hours. With a slow developer. Add in a day of testing to validate all changes, and there you go. A whole two days! <sarcasm>But hey, we are talking about Oracle here and we all know how secure they are.</sarcasm>
Another part of this whole fiasco is that other "Enterprise Level Application Servers" support this flag (WebSphere, Sun One Application Server a.k.a. - GlassFish). Heck, even the latest releases of Tomcat are getting ready to support HttpOnly thanks to Jim Manico.
Oh well. I guess we all have a choice. Be secure because you care or stick your head in the sand and act like the whole world is holding hands and singing Kumbaya.
7 comments:
@Matt: I sense some frustration, and I can sympathize as I had a similar "stupid problem" Oracle's "Web2Go" host-based personal web server/tool... A simple change would have bound the agent from 0.0.0.0 to 127.0.0.1... but it took them almost a year to get that change made - insane.
Problem is... these behemoths have so much code, so much process, so much do to it's actually semi-reasonable to take that long. Unless someone has a way to change the function of these massive organizations - this isn't going to change.
*sigh*
Thanks Rafal. I do understand that they have an exorbitant amount of code that goes into any of these products, and that a simple change is not always so simple.
In any case, I just thought I should share this nugget with the rest of the world, because when I received their response I was livid.
Thanks for reading, and I wish you the best.
We had a look at implementing this as well. The problem in our case is the servlet specification does not support it. It quickly becomes difficult. We work with Tomcat.
Some folks have started talking about creating a RFC for the HTTPOnly cookie flag:
http://groups.google.com/group/ietf-httponly-wg
HTTPOnly support for Apache Tomcat:
http://manicode.blogspot.com/2008/03/httponly-support-for-apache-tomcat.html
Need to add support for HTTPOnly session cookie parameter:
https://issues.apache.org/bugzilla/show_bug.cgi?id=44382
See Matt, the issue is that Oracle have abandoned their unsuccessful unbreakable campaign for the unfixable campaign.
Hi all, this goes without saying but we'll continue to see the knowledge gap, a prime example is with the recent Amex XSS. Most browsers have jumped on board with HttpOnly, what about the others?
@Jerry,
You are absolutely right. Luckily, there are other things we can do to add this flag manually.
Look http://blog.modsecurity.org/2008/12/helping-protect-cookies-with-httponly-flag.html and http://blog.modsecurity.org/2008/12/fixing-both-missing-httponly-and-secure-cookie-flags.html for some great news.
Thanks Matt. I talk briefly about HttpOnly on my blog http://jerrymangiarelli.blogspot.com
I like the phrase "What is old is new again" Really when you think about it, years ago it was the "Secure Flag" attribute, we made some movement, but we're still seeing the same issues over and over, even though we've been preaching for many years to include this flag, I can see this happening with HttpOnly.
Post a Comment