HttpOnly Crusade Update

I would like to report 2 exciting victories regarding the ongoing HttpOnly crusade!

1) The underlying network library used for Safari - the Qt C++ library - particularly the QNetworkCookie class - has finished adding HttpOnly support! See http://trolltech.com/developer/task-tracker/index_html?id=206125&method=entry for more information on the specific bug. My undercover Safari developer resource tells me that Safari is soon to follow with full HttpOnly support in both the Windows and OSX versions!

2) The latest version of the Servlet 3.0 specification (JSR 315) has added HttpOnly support to both the Cookie and SessionCookieConfig classes. You can download the JavaDoc here. Thank you to Rajiv Mordani @ Sun!

HttpOnly is not a cure-all. It's simply one defense-In-depth measure to assist in preventing XSS session hijacking attacks. HttpOnly can also be circumvented via triggering an AJAX request via the XMLHttpRequest object and reading cookie data out of the headers. Fellow HTTPOnly crusader, Eric Bing from Oracle, is also leading the charge communicating with the w3c regarding future specifications to prevent the XMLHTTPRequest JavaScript object from accessing HttpOnly cookies! Exciting!

In other HttpOnly news:

WebLogic is testing a HttpOnly flag and is currently reviewing the patch "for feasibility".

There is a FireFox bug already addressing the circumvention of HttpOnly via XMLHttpRequest headers as described above. Please consider adding you vote to help encourage the team to lock down this HttpOnly circumvention vector: https://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=380418#vote_380418

And the Crusade Continues......

ShakaCon 2008 Hawaii

You now have a business-critical reason to encourage your boss to send you to Hawaii. ShakaCon 2008 (June 9th-13th) is Hawaii's only information security, IT audit, compliance and ethical hacking conference!

For the second year running, one of the most beautiful places on Earth will serve as the backdrop for this truly unique security conference experience.

ShakaCon will include a wide variety of security speakers, including an update on the OWASP ESAPI (Enterprise Security API) project on June 11th. ShakaCon will also host a 2-day Web Application Security Training course by the Aspect Security Hawaii office on June 12th and 13th.
For more information, please see http://www.shakacon.org/ or download the registration form here.

CSRF Solutions

The problem: CSRF.

Jeremiah Grossman's explanation of the problem at RSA 08 :
http://www.slideshare.net/guestdb261a/csrfrsa2008jeremiahgrossman-349028/

OWASP CSRF Overview:
http://www.owasp.org/index.php/CSRF

Testing for CSRF:
http://www.owasp.org/index.php/CSRFTester

Java Filter for CSRF Protection:
http://www.owasp.org/index.php/CSRF_Guard

Java ESAPI Defense:
org.owasp.esapi.HTTPUtilities.addCSRFToken(String href)

Plaform's with built-in CSRF defense:
Drupal.org

ha.ckers.org pwnd?

It's strange and disheartening to see ha.ckers.org "down" this evening. I hope it's only unscheduled maintenance. I would hate to see the pwnders get pwnd!

Another interesting note: ha.ckers.org uses Wordpress? Ewwwwwwwwwwwwwwwwwww

Plaintext PCI Compliance

One of the main flaws of PCI-DSS compliance requirement #4 is that it allows for plaintext transmission of credit card information within private networks. The most recent mass-credit-card heist involves my favorite east coast grocer, Hannaford. Hannaford passed a PCI audit. Even more interesting, Hannaford passed their PCI audit on Feb. 27, 2008 - 2 months after they were breached - and 3 weeks before public disclosure! Just how did this happen?

"But in Hannaford's case, the intruders were able to intercept the data at a point where it obviously was unencrypted"

- Heather Paquette, Hannaford Manager Midwest Information Risk Management

"At the time of this potential exposure, Hannaford was certified to be in compliance with the highest security standards required by the credit card industry."

- Ronald C. Hodge, Hannaford's CEO

Anytime you transmit or store credit card information - do so using industry standard strong encryption.

This seems like a no-brainer. We should have learned this lesson in InfoSec 101!

HttpOnly, Safari, Servlets and Tomcat

I'm a huge fan of the benefits provided by the HttpOnly cookie flag, especially as it pertains to enhancing the security of session cookies in web applications. As we can see by Andrew van der Stock's recent blog post on HttpOnly Browser Support, almost every browser supports or will soon support the HttpOnly flag except for Safari.

Safari uses the WebKit.org open source project. And there is indeed a bug submitted for HttpOnly support in WebKit. But this bug was posted back in September 06' - whats taking so long? Unfortunately the problem is Apple. Apple is blocking WebKit from supporting HttpOnly. The CFNetwork library is the closed source Apple library that converts HTTPHeaders into objects - and the CFNetwork library does not support the HttpOnly cookie flag. Please do not hesitate to email the Apple Product Security Team to nudge them along in the right direction!

Also, I have heard rumors that the JEE Servlet Expert Group will soon agree to support the HttpOnly flag in the Servlet 3.0 specification! I'm absolutely thrilled about this. I cannot provide proof of this yet, but I am a longtime Sun contractor and have authoritative sources. This is a very encouraging development.

I've run across much resistance on my HttpOnly cookie crusade. The Tomcat team is hesitant to support this cookie flag since HttpOnly is not a standard - but I'm working on the Tomcat HttpOnly bug and am likely to get it rolled live into Tomcat once it becomes part of the standard for Servlets.

Vive la HttpOnly!

Actual Photo of Arshan Dabirsiaghi

HTTPOnly support for Apache Tomcat

I've made specific suggestions to the Apache Tomcat core developer team to add HTTPOnly support to Tomcat 5.5 (for starters). The adoption is slow-going since it involves changes to three of the most core files of Tomcat.
Here is how you can get HTTPOnly support NOW while you wait for official adoption.

1) First download the Tomcat source code and be able to build the core server via ANT. See http://tomcat.apache.org/tomcat-5.5-doc/building.html for instructions. Although the link above points to Tomcat 5.5, the changes I'm suggesting below will work for any Tomcat build.

Once you have downloaded the Tomcat code and have set up your build environment, you will need to make the following changes to at least org.apache.catalina.connector.Request.java and org.apache.catalina.connector.Response.java. You could (should) also make changes to org.apache.tomcat.util.http.ServerCookie.java if you require a very scalable solution where every StringBuffer.append matters; but that addition is beyond the scope of this post.

2) org.apache.catalina.connector.Request.doGetSession(boolean create) is where the session cookie (JSESSIONID) is initially created. You are going to need to change this. This first change is at approximately loc 2321 of the file org.apache.catalina.connector.Request.java (for Tomcat 5.5).

//this is what needs to be changed
//response.addCookieInternal(cookie);

//this is whats new
response.addCookieInternal(cookie, true);
}

3) In order to support the new HTTPOnly version of Response.addCookieInternal, we need to modify the functionality of org.apache.catalina.connectorResponse.addCookieInternal. The following are my suggested backward-compatible changes:

public void addCookieInternal(final Cookie cookie) {
addCookieInternal(cookie, false);
}

public void addCookieInternal(final Cookie cookie, boolean HTTPOnly) {

if (isCommitted())
return;

final StringBuffer sb = new StringBuffer();
//web application code can receive a IllegalArgumentException
//from the appendCookieValue invokation
if (SecurityUtil.isPackageProtectionEnabled()) {
AccessController.doPrivileged(new PrivilegedAction() {
public Object run(){
ServerCookie.appendCookieValue
(sb, cookie.getVersion(), cookie.getName(),
cookie.getValue(), cookie.getPath(),
cookie.getDomain(), cookie.getComment(),
cookie.getMaxAge(), cookie.getSecure());
return null;
}
});
} else {
ServerCookie.appendCookieValue
(sb, cookie.getVersion(), cookie.getName(), cookie.getValue(),
cookie.getPath(), cookie.getDomain(), cookie.getComment(),
cookie.getMaxAge(), cookie.getSecure());
}
//of course, we really need to modify ServerCookie
//but this is the general idea
if (HTTPOnly) {
sb.append("; HttpOnly");
}

//if we reached here, no exception, cookie is valid
// the header name is Set-Cookie for both "old" and v.1 ( RFC2109 )
// RFC2965 is not supported by browsers and the Servlet spec
// asks for 2109.
addHeader("Set-Cookie", sb.toString());

cookies.add(cookie);
}

Any feedback is appreciated.

PS: For more on HTTPOnly and how it can be a part of your defense-in-depth web application security strategy, see http://msdn2.microsoft.com/en-us/library/ms533046.aspx