Application Security Checklist

After the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors was released, I started adapting it into a checklist that developers could use during the software development life cycle to facilitate the development of more secure code.

I had reviewed the Top 25 document when it was first released and thought it was pretty good, however, after really diving into it while creating the checklist, I came to appreciate it even more. It's more than a list of the top 25 errors, the document includes guidance for different phases of the software development life cycle, from the design phase through implementation and testing. Some of the entries include code samples clearly demonstrating the errors. It's very comprehensive and any developer would be well served by studying it.

In my seven years as a full time developer, I never worked in an environment that relied on checklists, so I did some searching and happened across an excellent blog post by Brian St. Pierre on the subject.

When creating a checklist, it's important that it be structured such that questions are "yes/no" with affirmative answers indicating a secure situation. Negative answers indicate a problem. This permits reviewers to quickly scan the list for negative answers and follow up on only those issues.

Of course checklists don't guarantee secure software. Developers can lie, or misunderstand, etc. But I've seen firsthand there is value in having developers put their names on a checklist and go through it. Obviously the hope is that they will fully understand the issues and answer truthfully, but just by reading the document, they may learn about the issues and improve their code.

With that, here's the checklist. Please let me know what you think and feel free to use it as you see fit. I owe special thanks to Steve Christey of MITRE for allowing this derivative work.

Blended attacks for pen testers

When Dan Kaminsky microblogs about a security advisory, CVE-2008-3280 and says "brainmelt", you have to think it's something particularly good. He did destroy the internet after all.

If you haven't read CVE-2008-3280 it discusses findings by Ben Laurie and his team at Google in cooperation with Dr. Richard Clayton. In short, the advisory discusses awesomely powerful blended attacks that leverage Kaminsky's DNS findings and the entropy issues Debian suffered earlier this year and the lack of CRL checking by browsers. See (CVE-2008-0166).

Will this be the year of the blended attack? Recall CVE-2008-2540, the blended attack that relied on Safari's saving downloaded files to the desktop and the way Windows desktop deals with executables.

Along these lines, I am looking forward to the insights Ed Skoudis and Kevin Johnson will share at SANS Network Security 2008. Skoudis and Johnson are teaming up to deliver the keynote titled "The Ultimate Pen Test: Combining Network and Web App Techniques for World Domination."

In my own experience conducting web app pen tests, I've found command injection flaws that allowed me to execute arbitrary system commands as the Apache user. Granted running commands with Apache's privilege level isn't as good as being root (unless the box is misconfigured), but the Apache user can cat /etc/passwd, see who frequent users are via the last command, or depending on egress filtering, may be able to run traceroute from the web server to help map the network from the inside out, or download a pen tester's agent to facilitate deeper penetration. Ahem.

Or consider a web application that contains a Cross Site Request Forgery (CSRF or XSRF depending on who you ask) vulnerability. If such a flaw exists in the web based management interface for a network security device, we have a pen testing situation that will benefit from the skills of both the web app pen tester and the traditional pen tester. Sharpen your spears for a little targeted phishing. Use Google to find postings by the firewall administrator for the organization. What are the odds that admin will be logged into the firewall web gui for hours at a time each day? Craft a good email message with a tempting link for that admin, get him to click it while logged into the vulnerabe web app and you're way.

If someone like me with limited pen testing experience can think up simple ways like this to use a web app pen test as a force multiplier for a network pen test, imagine what Skoudis and Johnson, both experts in the field will have to say on the subject. Their keynote in Vegas will be one of the best infosec talks of the year.