Secure Development - Web Application Top 10 Summary

Since I started this series several months ago, OWASP has released its final version of its latest and greatest Top 10 list for 2010. In today's post, we will use this list to summarize the vulnerabilities covered so far and briefly talk about some of the new additions. For most of these, I have simply linked the title of the vulnerability to the corresponding post in my blog series.

1. A1-Injection
2. A2-Cross Site Scripting (XSS)
3. A3-Broken Authentication and Session Management - I covered this in two separate posts ("Authentication" and "Session Management")
4. A4-Insecure Direct Object References - I mentioned this in my "Secure Storage" post, see recommendation 4.
5. A5-Cross Site Request Forgery (CSRF)
6. A6-Security Misconfiguration
7. A7-Insecure Cryptographic Storage
8. A8-Failure to Restrict URL Access - My "Access Control" post dealt with many different access control issues, including direct URL access
9. A9-Insufficient Transport Layer Protection - I did not have a separate post on this issue, see below for details
10. A10-Unvalidated Redirects and Forwards - This is a specific type of input validation issue, but I did not single it out in my "Input Validation" post; see below

A9-Insufficient Transport Layer Protection - Basically, this refers to a failure to encrypt the application's network connections properly. This is especially crucial for Internet-facing applications, but the same standard should be applied to internal connections, both for intranet users and back-end connections to other systems. Basically, assume that your network is compromised and the attacker can see all unencrypted traffic. Be sure to use standard encryption algorithms and APIs to avoid the implementation pitfalls of home-grown security software.

A10-Unvalidated Redirects and Forwards - Anytime your application redirects or forwards requests, it should carefully validate the source of the forwarding information. Otherwise, an attacker can use it to redirect to a phishing site or use forwards to bypass poorly-implemented access controls. Ideally, no user input should be used in the forwarding process: for example, you could store the possible forwarding URLs in a database table indexed by a unique ID. At worst, the attacker could change the ID number to forward to a different URL on the list of valid forwarding URLs.

Summary

The previous blog posts have covered some of the most common vulnerabilities found in both web application and traditional development. For each vulnerability, we have reviewed specific countermeasures that developers can take to ensure their application is better protected against these common issues. If you remember only three things from this series, remember the following:

1. Input Validation
2. Authentication
3. Access Control

Getting just these three things right can go a long way towards making your application more secure than the vast majority of code out there. Good input validation can help prevent or mitigate most other vulnerabilities, solid authentication raises the bar for attackers to get in, and proper access control protects you from malicious (or clumsy) insiders.

What's Next

Now that we have covered the Top 10 application vulnerabilities, the blog will take a step back and focus on security as part of the larger development lifecycle. Next time, we'll start with a general introduction to some of the different secure development methodologies out there, including OWASP's Software Assurance Maturity Model (SAMM).