#6 of the Top Vulnerability Discoverers of 2009

As I was last year, I am again pleased to report that the vulnerabilities I've been happily and responsibly disclosing and posting have resulted in 6th place on the list of Top Vulnerability Discoverers of 2009. Thanks to Scott Moore of the IBM ISS Frequency X Blog who compiled the list for 2009.
I remain both pleased and disconcerted to find myself on this list and wish to convey a few thoughts on the subject.

1) First, a reminder that my work has focused entirely on vulnerable web apps and pales in comparison to the likes of others named on both the all-time list and the list for 2009. Congratulations and well done to you all.

2) My efforts resulted in what the Frequency X post indicates is 48 unique web application vulnerabilities in 2009. This again serves as a stark reminder of what a challenged state of affairs the development process is for so many web application vendors. May the SDL and its ilk prevail.

3) I will continue my discovery and reporting efforts with the intention of somehow making a dent in the statistics (unrealistic, I know). I focused heavily on cross-site request forgery (CSRF) issues in 2009 and was not surprised to find that the average number of days for CSRF vulnerabilities to be resolved increased by 37 days to 93 days.



The above figure can be found on page 7 of the 8th Edition of WhiteHat's Website Security Statistics Report.
I believe, as the report states, that much of the reason CSRF issues linger unabated is that "no one at the organization knows about, understands, or respects the issue."
I can tell you from personal experience, I heard this many times in 2009.
It should therefore surprise no one that CSRF is number four on the 2010 CWE/SANS Top 25 Most Dangerous Programming Errors.
Hopefully, each application discovered and reported as vulnerable to this issue leads to a downward statistical trend in the likes of the WhiteHat report.

I look forward to continued discussions of these issues with you, dear readers, and hope we can make a difference.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

PHPIDS: Attack Me, Please!

Of the many projects I've had the pleasure of reviewing for toolsmith over the past few years, one of my absolute favorites is PHPIDS.
PHPIDS (PHP-Intrusion Detection System) is a simple to use, well structured, fast and state-of-the-art security layer for your PHP based web application.
The IDS neither strips, sanitizes nor filters any malicious input, it simply recognizes when an attacker tries to break your site and reacts in exactly the way you want it to.
More specifically, PHPIDS enables you to see who is attacking your site and how, and all without the tedious trawling of logfiles or searching hacker forums for your domain.
PHPIDS is subject to minor releases every few months, and the release of 0.5.4 (the last minor release before 0.6) just before Christmas reminded me to invite you, dear reader, to kick the crap out of it.
Give it all you've got, beat on it. Really. That's the idea.
The PHPIDS Demo Smoketest will test how 1337 your mad web app testing skills are and give you a grade for overall impact, just like in school...the school of XSS, the school of leetness, the interlocutor of insertion.
So enjoy, and see what you've got in the way of evasive techniques and pwnage prowess.
I can see it now...I pass and receive an overall impact rating of 54. "Wow!", I say. "That's got to be as good as something Gareth Heyes might utilize to circumvent the centrifuge!"
To which David Ross says "Hah! I know Gareth Heyes, and you sir, are no Gareth Heyes!"
*sigh* I feel so inadequate. Life as a white hat script kiddie is teh sux0r.

Enjoy. ;-)
http://attackmeplease.holisticinfosec.org/
Should you wish to read my article on PHPIDS, from the July 2008 ISSA Journal, it's here.

Most importantly: PHP web app developers and site operators one and all: give PHPIDS a close look and consider utilizing it to improve your offering's security. I promise you, you'll quickly learn where your code passes muster and where it doesn't.

del.icio.us | digg | Submit to Slashdot