February OWASP – Top 10 Exploits
We’ll review OWASP in a moment. First I wanted to give you an update on the week. This upcoming week should be pretty interesting. Monday, Microsoft will hold a Service Lifecycle Management seminar at their Mason offices. Then Monday evening (and the two following Mondays) seniors in UC’s College of Applied Science (CAS) IT program will present functional prototypes of their senior designs. Tuesday is the Agile Round Table. On Thursday, LUCRUM CEO, John Bostick, and I will lead a discussion with Xavier professor Tim Kloppenborg’s Project Management class. I’m looking forward to a lively discussion there.
I serve on the CAS IT Program Advisory Board, and I attended the proposal presentations back in the first quarter. I’m eager to review progress. I’m especially looking forward to Brian Krahenbuhl’s .NET 3.5 implementation of a dog grooming business management system, David Parks’ and Erin Osterfelds’ Coldfusion Framework built around Fusebox, and also Craig McRae’s animation tool presentations. I had an opportunity to judge last year’s senior design competition and expo held at the Duke Energy Center and cajoled runner-up Rob Lindley, 2007 CAS IT student of the year, to come work for us at LUCRUM. I stole Rob from a good friend and business owner, Glen Wernersbach. Yeah, we’re still friends
On to OWASP. For a cold, icy evening, last Tuesday, the OWASP meeting was worth the effort. Marco Morana leads the group, and he presented on the OWASP Top 10 web application security flaws. In his day job, Marco is a Sr. Director at Citigroup and serves as a Technology Information Security Officer. I’m guessing that when things don’t go so well Marco is the one that gets the call Marco recently published Web application vulnerabilities and insecure software root causes: solving the software security problem from an information security perspective in the latest issue of [IN]SECURE magazine (p. 30) where example source code behind some of the vulnerabilities can be found.
Marco started with a medical analogy equating sickness to a response to something that has happened in the body and then drew strong parallels between application weaknesses and physical sickness. In these terms, a security assessment is similar to a doctor’s exam. Both serve as a means to understand what’s causing the sickness. After assessment a diagnosis can be made based on the symptoms, drilling down to the root causes, and finally determining the underlying risk factors. Most security issues boil down to inherent design flaws, coding errors, and insecure configurations.
We covered the actual Top 10 list in the DevCares post a few weeks ago, so I’m not going to rehash it here. You will want to read Morana’s article which provides tangible examples of application and coding implementations that cause the issues.
When you’re faced with an exploit in a production system you may not have time to strategically fix the issue because you just need to stop the bleeding. Hopefully you won’t have to get to this point before your enterprise provides the resources to develop strategies to produce secure applications, but you may find yourself in this situation. Think about this ahead of time, no – think about it right now, and begin developing a business case for your security resource requirements and quantify ROI for your business people. What do you risk by not having a strategic focus on web application security? The financial cost could be great if your company is found liable for the release of personal information. You also risk a sullied reputation and potential loss of customers even if the real financial liability is not terribly great.
How do you mitigate the risks associated with application in-securities? A number of tools are available, many of them under an open source license, that can perform white and black box testing, code scans for authorization requests that depend on automatic credentials instead of user input, and other functions to catch some of the coding and functional weaknesses of an application. Also, develop a testing methodology that targets security testing early in the SDLC where the cost to correct is generally much smaller than if an issue reaches production. Schedule code reviews, create standards, and perform audits of your systems so that enterprise development teams understand the seriousness and willingness of your enterprise to devote resources to ensuring secure applications.
As with most Tuesday evening meetings I attend, I needed to leave early to get my daughter from dance class. Marco reviewed a number of interesting resources before I left. They are:
California bill 1386 was also mentioned as it has far reaching effects on the storage and disclosure of personal information.
PCI compliance (pdf) for encrypting PANs (CCN’s or Primary Account Numbers).
And finally, a State of Minnesota law that prevents storage of credit card magnetic strip information, CVV2 and PINs.
As the meeting wrapped up, or more accurately, right before I had to leave, a discussion began about how to identify and defend against Cross Site Request Forgery, or CSRF, vulnerabilities. This will probably be covered as its own subject in a future discussion as it is such a deep and complex subject. In the meantime you can find testing strategies and tools to identify and help defend against CSRF exploits.