Diary of a Hacker - Introduction
I work for a web development and hosting firm, where have an ongoing competition. Our webapp developers submit their newly-built sites for a voluntary cracking attempt. If I cannot in some way compromise, abuse, DOS, or gain escalated privileges, the developer in question gets a monetary prize.
So far, I have not failed, and the prize keeps getting bigger.
Of course, it isn't really a code audit or even a penetration test. Primarily, it's a way for me to hone my own skills while informing our developers about web security issues. The contest has a somewhat limited scope- I must get in by abusing a hole in the code or configuration, so social engineering, server configuration, and other attacks are out (at least as the primary attack vector, though I may use them as leverage against another hole). It also is limited to single-developer applications, so they tend to be small in scale.
I'm writing about this here for two reasons. First, I think it's a very good idea. We have had an extremely positive response from the developers. They code better than ever. They are actively engaged in maintaining the security of the applications, rather than building and then forgetting about them. The contest has sparked many insightful discussions about various security concepts, including CAPTCHA, PHP session management, and XSS filtering. If anybody out there manages a team of developers, I highly recommend holding a similar competition.
The second reason is because I've received permission from the higher-ups to publish some of the post-exploitation writeups on this blog. I hardly consider myself to be the best web application hacker out there, and I don't think I'm a definitive authority on the subject, but I've found (and I'm not alone) that very few non-security people, particularly the developers in charge of building the applications, know how an attacker works.
I'm hoping that by showing the thought process and techniques that I use, I can enlighten a few developers, project managers, and maybe even a few other security-folk.
So far, I have not failed, and the prize keeps getting bigger.
Of course, it isn't really a code audit or even a penetration test. Primarily, it's a way for me to hone my own skills while informing our developers about web security issues. The contest has a somewhat limited scope- I must get in by abusing a hole in the code or configuration, so social engineering, server configuration, and other attacks are out (at least as the primary attack vector, though I may use them as leverage against another hole). It also is limited to single-developer applications, so they tend to be small in scale.
I'm writing about this here for two reasons. First, I think it's a very good idea. We have had an extremely positive response from the developers. They code better than ever. They are actively engaged in maintaining the security of the applications, rather than building and then forgetting about them. The contest has sparked many insightful discussions about various security concepts, including CAPTCHA, PHP session management, and XSS filtering. If anybody out there manages a team of developers, I highly recommend holding a similar competition.
The second reason is because I've received permission from the higher-ups to publish some of the post-exploitation writeups on this blog. I hardly consider myself to be the best web application hacker out there, and I don't think I'm a definitive authority on the subject, but I've found (and I'm not alone) that very few non-security people, particularly the developers in charge of building the applications, know how an attacker works.
I'm hoping that by showing the thought process and techniques that I use, I can enlighten a few developers, project managers, and maybe even a few other security-folk.
Labels: Audits, Diary of a Hacker, Web Applications
posted by mckt at
2:31 PM
0 Comments:
Post a Comment
<< Home