Top-10 Web Application Security Vulnerabilities (2007) | Hacker News Reader

Top-10 Web Application Security Vulnerabilities (2007)

owasp.org

19 pointsJabavuAdams10 comments

The Top-10 is just a start. As a penetration tester and sometimes-trainer, I find it's when developers start to see practical demonstrations of what these vulnerabilities can actually allow a malicious party to achieve that the eyes really get opened. Particularly when those demonstrations are within their own applications.

Check out the rest of the OWASP site, and play with WebGoat (http://www.owasp.org/index.php/Category:OWASP_WebGoat_Projec...).

Take a look at the 'Web Security' section here: http://code.google.com/edu/courses.html

Start following some of the many webappsec blogs floating around the interwebs, subscribe to mailing lists, read tweets: http://www.gnucitizen.org/ http://ha.ckers.org/ http://jeremiahgrossman.blogspot.com/ http://www.webappsec.org/lists/websecurity/ http://twitter.com/#search?q=%23WebAppSec

There is a huge amount of information out there.

Thanks, that's great information. Do you mind if I add it to the (public) notes on my web-page? How should I cite you?

Go for it, no need to cite.

Posted. Cited anyway.

http://www.shinyfish.com/wiki/WebApplicationSecurity.html

Obligatory link to the 2010 list of the top 10 risks: http://www.owasp.org/index.php/Top_10_2010-Main

Interesting how many items are still there from 2004 to 2007 to 2010.

Argh, didn't see that. Thanks.

IIRC, I think I analyzed and organized those pages in 2007. Looks like the big ones (XSS, injection) are still pretty much the same. In fact, looks like most of my work is pretty much the same, but some shiny new graphics have been added. :)

You'd be surprised at the number of pages I come across that still have these basic insecurities. Thankfully, automatic checking is making really basic CSRF attacks less prevalent.

I'm sure tptacek or someone more familiar with the current hotlist would have more to say, though.

I'm on a team that is writing documentation for developers to mitigate the OWASP Top 10 and CWE 25. You'd be surprised how many intelligent, bright developers think that because their code is behind the firewall it is safe and acceptable to leave those kinds of holes wide open.

Add SSL to the list, along with hidden form parameters and request headers. It's as if nobody's ever heard of using cURL or an HTTP proxy, even if for debugging purposes.

We're actually covering code analysis, testing, and fuzzing tools as well. Great depth of information coming out of this thing. :)

Reply on news.ycombinator.com