Saturday, February 28, 2009

OWASP Podcast #10 - an interview with Ken van Wyk

OWASP Podcast #10 - an interview with Ken van Wyk - is live!!

Ken began to approach application security professionally a lot earlier than most folks. I believe his pragmatic and level-headed perspective is of value to anyone in the information security biz.

To listen to OWASP Podcast #10 you can, download the mp3 file directly , subscribe to the RSS feed or subscribe directly through iTunes!

Wednesday, February 25, 2009

Apache Tomcat HttpOnly Support Saga Continues

I see Mark Thomas from Apache still trying to get resolution on the whether to back-port the Apache Tomcat 7 HTTPOnly session-id attribution (per Java Servlet 3.0) into Tomcat 6 (a Servlet 2.5 container). The patch has been complete for well over 5 months and is still awaiting approval. What's more important here; standards or security?

For more info:
Update: HTTPOnly is now supported in at least some versions of Tomcat!

Thursday, February 19, 2009

OWASP Podcasts #8 and #9 - Newscast

Hot off the press, OWASP Podcasts #8 and #9 are now live!

OWASP Podcast #8 and #9 make up a 2 part Newscast featuring Andre Gironda, Jeff Williams and Arshan Dabirsiagh hosted by me, Jim Manico(de!).

To listen to OWASP Podcast #8 you can, download the mp3 file directly, subscribe to the RSS feed, subscribe directly to iTunes, or listen right now!

To listen to OWASP Podcast #9 you can, download the mp3 file directly.

We cover a very wide array of news topics, listed here.

Sunday, February 15, 2009

HTTPOnly on Tomcat Update

The following note was sent to the Apache Tomcat DEV community on 2/13/2009 by Mark Thomas, the Tomcat lead. This has been quite an ordeal - it's been over a year and still we are debating the HTTPOnly patch in Tomcat! *sigh*


The implementation of httpOnly support in Tomcat 7 fits well with the previous
httpOnly patch [1] that is currently the proposed backport for 6.0.x

When originally proposed there was some concern that the v3 servlet spec may
require some changes. This hasn't been the case. With that in mind could folks
please review their comments and votes for this patch. I'd like to get it into
6.0.19 if posible.

If you still think there is room for improvement, I'm happy to take another look
at this. Some pointers as to how you think things could/should be improved would
be appreciated.

If you do vote for this patch, please remember to indicate your preference for
using or not using httpOnly for session cookies by default.


Facebook Throttling Rate of New Friends

Take a look at this CNN TechNews article on Facebook Friend padding.

This article has apparently nothing to do with AppSec. However, this paragraph caught my eye:

"After (Facebook User Zorn) had sent 180 friend requests in less than an hour, an automated note from Facebook popped up on his screen warning him to stop or he’d be kicked off the site."

I think is a excellent defensive coding technique from Facebook. A defensive technique like this would have stopped the MySpace SAMY XSS worm. Samy's worm esentially added friends to his profile so fast and frequently that it took down the global myspace cluster. This friend-adding “throttling” feature could have stopped or slowed down that attack.

This feature is a wise move that will not disturb the vast majority of users. Go Facebook for your appSec excellence!

Friday, February 13, 2009

OWASP Podcast #7 Interview with Jeff Williams

We just pushed OWASP Podcast #7 - an interview with Jeff Williams - live!.

We discussed Jeff's involvement in OWASP, builders vs breakers, his work on the XSS prevention cheatsheat and of course - ESAPI. Jeff also directly responded to several of Gary McGraw's comments from OWASP Podcast #5 - and did not hold back any punches. This one is sure to please.

To listen to OWASP Podcast #7 you can, download the mp3 file directly, subscribe to the RSS feed, subscribe directly to iTunes, or listen right now!

Long live the king!

Shout out to my co-producer, Kevin Coons from ManaTribe. Keep up the good work, Kevin - we are just getting started!

Tuesday, February 10, 2009

Threat Classification v2 on Logic Flaws

MANICODE would like to say thank you to guest blogger Bil Corry who wrote this excellent section for the upcoming "Threat Classification v2 on Logic Flaws". I found his inclusion of recent real world examples to be fascinating!

Threat Classification v2 on Logic Flaws - Real World Examples
By Bil Corry

* Yahoo had a promotional offer where if you deposited USD $30 into an advertising account, Yahoo would then add an additional USD $50 to that account. The sign-up process was able to be circumvented in such a way that failing to deposit the requisite USD $30 still allowed the additional USD $50 to be credited to the account.

Yahoo SEM Logic Flaw

* Tower Records' form validation assumed that the user would fill out a form in the order presented, but in reality, some users filled out the bottom portion first, causing a bug that wasn't caught during development and resulted in the loss of sales.

Tower Records Tunes Its Site

* YouTube restricts some videos to users that are 18-years-old and older on their site. However, if the same video is embedded in another site, then the process that filters the videos is bypassed, allowing anyone of any age to view the video.

Youtube’s 18+ Filters Don’t Work

* Facebook restricts access to private user pages, but there have been incidences where an attacker can replace the user ID in the URL with a victim ID, thereby circumventing the security measures. Two examples include accessing private photos and accessing private fan pages.

Peekaboo! Facebook fills photo security hole

Hole unveils Facebook fan pages

* E-trade and Schwab failed to limit one bank account to any given user, allowing an attacker to assign the same bank account to tens of thousands of users, resulting in a loss of USD $50,000.00.

Friday, February 6, 2009

double-submit cookie CSRF defense and HTTPOnly

Let's start with reviewing the Wikipedia paragraph on this subject.

A variation on this approach is to "double submit" cookies. If an authentication cookie is read using JavaScript before the post is made, JavaScript's stricter (and more correct) cross-domain rules will be applied. If the server requires requests to contain the value of the authentication cookie in the body of POST requests or the URL of dangerous GET requests, then the request must have come from a trusted domain, since other domains are unable to read cookies from the trusting domain. On the other hand, this method forces users to enable JavaScript.

They are suggesting that you build your HTML form in a way that at the time the form is posted, javascript gets called which reads the session cookie and places that cookie in the body of the html (or part of the form post payload as a normal form element). The server would then verify that the session id is valid in both the session cookie and the html body (or form post payload). If the CSRF attack code was hosted on a different server than the victim server, this "session cookie transfer to body" code would fail due to the cross domain rules. Not an unreasonable defense!

The scenario for CSRF defense would not work in the face of HTTPOnly. BUT - I can circumvent this defense by placing CSRF attack code on a cross-site that reads the cookies out of an XHR header (since they are not httponly for this defense), and adds it to the post manually. This lets an attacker circumvent double click defense!

Now, as browsers handling of XHR matures, the validity of this claim gets stronger (the claim that double-click defense is good).

IE lets you read cookies out of XHR request headers (that are not httponly) which would let an attacker circumvent the double-cookie defense like I described above. FireFox is vulnerable to this defense too, prior to Starting with FireFox, cookies - any cookies - are no longer included in Firefox XHR response headers.

HTTPOnly will block this defense from working, since it depends on JavaScript reading cookie in the context of the current domain.

In a world where you can no longer read ANY cookies from XHR headers, AND httponly is in widespread use - I can see an argument to not use HTTPOnly depending on the risk - which is why implementers for server side products should provide options to disable HTTPOnly! :)

Wednesday, February 4, 2009

FireFox HTTPOnly Champion!

FireFox is truly an HTTPOnly champion!

I want to extend sincere congratulations the the entire Mozilla team. For the first time in history, a browser has been released that completely supports the HTTPOnly cookie flag, including protection against leakage of HTTPOnly cookies via XHR response headers.

The JavaScript document.cookie call has been blocked for HTTPOnly cookies since FireFox The problem that delayed true comprehensive HTTPOnly support in FireFox, as described by the bug entry states: "XMLHttpRequest subverts the idea of HTTPOnly cookies since it allows sending a request and reading of Set-Cookie or Set-Cookie2 headers in the response - even if it has HTTPOnly flag set."

IE 7/8 is very close to complete HTTPOnly support. When we test IE 7.0.5730.13 against - the result is set-cookie2 leakage. At least set-cookie is not leaked. (Note that even though IE exposes a set-cookie call below, it was a non-httponly cookie, so the exposure is reasonable.)

But look at the test results of FireFox - ALL SET COOKIE(2) CALLS ARE REMOVED! Even non HTTPOnly cookies are now removed from the XHR request headers!

Sincere congratulations the the entire Mozilla team. I applaud your dedication to web application security excellence!

Monday, February 2, 2009

Servlet Containers and HTTPOnly support

Oracle (acquired BEA Jan 08) Weblogic is not playing ball at all:

Apache Tomcat JSESSIONID Cookie: A developer submitted a patch to Apache Tomcat, which is close to going live in Tomcat 7 for sure soon (aiming to be a 3.0 servlet container). The core developers are voting to decide on whether to include HTTPOnly support for Tomcat 5/6 right now.

IBM Websphere: (Sept 08) "WebSphere Application Server has been modified to properly recognize, accept and process HTTP-Only cookies. This support is targeted for fixpacks and Please review the recommended updates page at for more information."