Sunday, March 30, 2008

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!

Thursday, March 27, 2008

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 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

Sunday, March 9, 2008

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 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 and You could (should) also make changes to 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 (for Tomcat 5.5).

//this is what needs to be changed

//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())

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(){
(sb, cookie.getVersion(), cookie.getName(),
cookie.getValue(), cookie.getPath(),
cookie.getDomain(), cookie.getComment(),
cookie.getMaxAge(), cookie.getSecure());
return null;
} else {
(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());


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