Disclaimer: The opinions of the columnists are their own and not necessarily those of their employer.
Kenneth F. Belva

bloginfosec.com Interviews Jeremiah Grossman on Web App Security

One of the many blogs on which I keep a close eye is that of Jeremiah Grossman. His expertise is in web application security. I made his acquaintance at the 16th Annual NY Metro ISSA conference and had the good fortune to watch his Cross Site Request Forgery (CSRF) presentation.

I had the chance to interview him after the conference. Below you will find the correspondence. Enjoy!
______

Your presentation at the NY Chapter of ISSA went very well.

Thank you!

Cross Site Request Forgery (CSRF) is a very serious issue that doesn’t seem to get enough attention, could you give our readers a bit on CSRF, its connection with Cross-site scripting (XSS) and why such a serious issue has not receive as much attention as it should.

CSRF has been known and written about since the 2000 and 2001 timeframe, but has remained relatively obscure till around 2005. Essentially CSRF is when an attacker forces a victims browser to do something on another website they didn’t intend. For example while reading this blog post, hidden code in the background could have forced your browser to conduct wire transfers, send web mail spam, hack another web site, alter your MySpace profile, or just about anything else. CSRF and XSS attacks are dangerous and incredibly effective independent of each other. However, when they are used in combination and they increasingly are, much more destruction is made possible, including Web Worms.

What solutions can you give developers to help them fix XSS and CSRF?

For XSS the answer is easy, though much more difficult in practice:

1) Input validation: Don’t use what you don’t expect to receive, the most restrictive the better. Ensure any incoming data has the proper character-set, minimum and maximum length restrictions, and is formatted properly. These steps will not only help wipe-out XSS, but a vast number of other vulnerabilities as well.

2) Output filtering: HTML-encode any user-supplied data before printing it back to the web browser:

$data =~ s/([^\w])/’&#’.ord($1).';’/sge;filter HTML

CSRF is a little bit more complicated. What needs to happen is valid requests to any “important” feature on a website should be made unpredictable. Meaning, any attacker would be unable to blindly manufacture a valid request for a user. This is typically done through the use of a request token based upon the users session ID. One very simple example:

http://bank/wire_transfer.cgi?from=10&to=1&amt=100&token=abc

The wire_transfer.cgi application would know if the request is valid by comparing the “token” parameter value to that of the users session cookie. If the logic works out, we know the user intended the request because with CSRF, the attacker does not know the users session ID ahead of time. While this work what many do not know is that any CSRF solution fails when a websites is vulnerable to XSS, so both have to be fixed at the same time.

What are some of your favorite tools to use in your personal research to discover web app vulnerabilities?

For tools I use Firefox with LiveHTTPHeaders and the Web Developer toolbar. That combination will net at least a handful of vulnerabilities on the average website. When needing to full assess an entire website (or thousands), we use our proprietary scanning platform, Sentinel, as part of our outsourced service.

What’s your take on the 2007 OWASP Top Ten?

An great document with some excellent data. A much needed improvement for the previous version.

What advice would you give the not-so-tech savvy end user about surfing the ‘net via their browser (with a concentration on IE7)?

The Web has become an extremely hostile environment no matter what web browser your using. For basic security I make sure everything remains patched, well configured, with a splash of security toolbars for good measure. For added security, and this is what many experts are already doing, separate surfing habits with two web browsers. The first web browser is for everyday Web surfing where no important personal/financial business is EVER conducted. The second web browser is ONLY used for “important” online business like web banking or email. This browser is opened for very limited amount of time and never goes anywhere else expect those trusted web sites. This behavior limits the window of opportunity for a number of attack techniques.

Jeremiah, thanks for your time and for an insightful interview.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*