OWASP Podcast #2 Securing Webgoat with ModSecurity

I just finished publishing OWASP Podcast #2 - an interview with Stephen Craig Evans.

We discussed Stephen's OWASP Summer of Code Project, Securing Webgoat with Mod Security.

You can check out the show notes for OWASP Podcast #2, download the mp3 file directly, subscribe to the RSS feed, or subscribe directly to iTunes.

I found Stephen to be very interesting in his analysis of when WAF deployment is prudent. Although WAF deployment is something I personally think of as a last resort, intelligent discussion and arguments like I heard from Stephen make it tougher for me to dismiss WAF technology outright. Great job, Stephen!

HTTPOnly XMLHTTPRequest exposure update

The HTTPOnly crusade grows stronger.

I have victories to report on several fronts regarding the adoption of HTTPOnly, to the point of stopping XMLHTTPRequest.getAllResponseHeaders leakage of HTTPOnly cookies.

The HTTPOnly world was rocked in the Summer of 2007 when the famous HTTPOnly test url at http://ha.ckers.org/httponly.cgi demonstrated that HTTPOnly cookies could be exposed via the JavaScript XMLHTTPRequest (XHR) object through the getAllResponseHeaders function which includes HTTP headers that contain set-cookie headers - even for HTTPOnly cookies.

So even though HTTPOnly cookies stopped JavaScript calls like document.cookie, they did not stop advanced XSS techniques like http://insanesecurity.wordpress.com/2007/08/01/httponly-vs-xmlhttprequest/

The latest and greatest browsers and standards address this issue.

First out the gate, is Internet Explorer. My HTTPOnly hat's off to Microsoft for delivering the first browser to implement defense from the HTTPOnly exposure vector described above. http://www.microsoft.com/technet/security/bulletin/ms08-069.mspx

However, IE did NOT implement protection from set-cookie2 header exposure!! The horror!

I still declare the HTTPOnly browser war active!

Will FireFox deliver the first browser to truly implement complete HTTPOnly in a way that would make the HTTPOnly working group pleased? Could Opera, Safari or Chrome sneak in with a win?

As I mentioned in an earlier post, some of the recent editorial version of the XHR specification at w3c includes clear verbiage that prevents reading of ALL set-cookie/2 headers via getAllResponseHeaders() and getResponseHeader() in a case insensitive way. Nice!

It's the securing of these core RFC's that help make the applications and browsers of tomorrow more secure. Thanks Anne!

PS: As a HTTPOnly bonus, check out Ryan Barnett's blog post on how to add HTTPOnly protection using ModSecurity.

How to restart Tomcat properly

David: hmm, i get no cancel confirmation

James: update all code

then refresh

then project-clean

sacrifice 2 chickens

reload tomcat

sacrifice a goat

then you should be ok

David: ok, i forgot the goat

OWASP Podcast #1

I am very pleased to announce the inception of the OWASP Podcast series.

OWASP Podcast #1 was recorded on November 21, 2008. The guest panel includes Jeff Williams, Arshan Dabirsiaghi, Jeremiah Grossman and your host, Jim Manico.

You can download OWASP Podcast #1 here.

You can read the show notes here.

You can subscribe rss/itunes/feedburner here.

Thank you, very much, to all participants and listeners. Please pass the word!

This is only the beginning. My hope is that the OWASP podcast series serves the community well.

Enjoy!

XMLHttpRequest will be more secure in the future

Some of the most recent iterations of the XHR specification at w3c (edited by Anne van Kesteren) includes excellent security choices which will lock down the JavaScript HTTPOnly edge-case exposure vectors.

The latest editorial draft of the XHR w3c spec http://dev.w3.org/2006/webapi/XMLHttpRequest/

• prevents creating set-cookie/2 headers via setRequestHeader() in a case insensitive way. (but XHR is free to send Cookie/2 headers for any existing cookie (HTTPOnly or otherwise).
• prevents reading set-cookie/2 headers via getAllResponseHeaders() and getResponseHeader() in a case insensitive way.

Excerpts from the spec:

getAllResponseHeaders(), method….
Return all the HTTP headers, excluding headers that case-insensitively match Set-Cookie or Set-Cookie2, as a single string, with each header line separated by a U+000D CR U+000A LF pair excluding the status line, and with each header name and header value separated by a U+003A COLON U+0020 SPACE pair.

setRequestHeader(header, value), method
For security reasons, these steps should be terminated if the header argument case-insensitively matches one of the following headers:
• Accept-Charset
• Accept-Encoding
• Authorization
• Connection
• Content-Length
• Cookie
• Cookie2
• Content-Transfer-Encoding
• Date
• Expect
• Host
• Keep-Alive
• Referer
• TE
• Trailer
• Transfer-Encoding
• Upgrade
• User-Agent
• Via

I’m excited to see this key specification move in such a secure direction!

Java and UTF-8 Shortest Form

Java 6 update 11 contained an interesting change to UTF-8 handling that I think is worth noting.

Here is the original JRE bug:
4486841 UTF-8 decoder should adhere to corrigendum to Unicode 3.0.1

Here is the impact of the problem
The UTF-8 (Unicode Transformation Format-8) decoder in the Java Runtime Environment (JRE) accepts encodings that are longer than the "shortest" form. This behavior is not a vulnerability in Java SE. However, it may be leveraged to exploit systems running software that relies on the JRE UTF-8 decoder to reject non-shortest form sequences. For example, non-shortest form sequences may be decoded into illegal URIs, which may then allow files that are not otherwise accessible to be read, if the URIs are not checked following UTF-8 decoding.

The solution is to flat out reject anything other than shortest-form UTF-8 per http://unicode.org/versions/corrigendum1.html which has been around since - March 2001??

• In UTF-8, <004d> is serialized as <4d>.
• The problematic "non-shortest form" byte sequences in UTF-8 were those where BMP characters could be represented in more than one way. These sequences are illegal...