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!

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:

• Recent Apache Tomcat HTTPOnly activity
• Actual Apache Tomcat HTTPOnly patch, on deck

Update: HTTPOnly is now supported in at least some versions of Tomcat! http://manicode.blogspot.com/2009/03/httponly-supported-in-tomcat-6019.html

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.

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*

Folks,

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.

Cheers,
Mark

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!

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!

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
http://ha.ckers.org/blog/20080616/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
http://www.storefrontbacktalk.com/story/021005tower.php

* 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
http://www.darkseoprogramming.com/2008/06/01/youtubes-18-filters-dont-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
http://news.cnet.com/8301-1009_3-10042909-83.html

Hole unveils Facebook fan pages
http://news.cnet.com/8301-1009_3-10046932-83.html

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