Secure ASP.NET
The Open Web Application Security Project s Top 10
By Don Kiely
The Open Web Application Security Project (OWASP) is an interesting community dedicated to making Web applications more secure. It has a wealth of resources that can help you develop, purchase, and maintain secure applications. At any given time it has a few dozen projects of various types, such as requirements and metrics, education, tools, and honeycomb projects, spanning all platforms and technologies including .NET. If you are concerned about the security of your Web applications and aren t familiar with OWASP, I suggest you explore their Web site now.
One of their more interesting and ongoing projects is the OWASP Top 10 Project. Updated every few years to stay representative to evolving threats, the list represents a consensus of the most critical Web application security flaws. Although it is completely devoid of the humor of a Letterman Top 10 List, OWASP s list is useful in myriad ways. If you re a developer, it s a great resource for making sure you have the skills to create secure Web sites. If you re an organization with a Web site, it can form the basis for a security review of the site to identify security problems. It isn t a panacea, but, because it represents the most prevalent threats on the Web today, it provides a solid foundation for secure applications.
I urge you to download and read the complete Top 10 2007 report, available as a PDF in English and Korean, with other languages coming. Here is my summary of the list:
1) Cross-site Scripting. This is one of several classes of attacks that embeds code in data. Attackers can cause script to execute in a browser with all sorts of nasty consequences.
2) Injection Flaws. It s a bad sign that the first two items on the list take advantage of code as data. The most common version of this type of flaw is SQL injection, where hostile commands execute as part of SQL statements. Probably the biggest problem here is that the hostile code executes with the permissions of the application, which all too often are administration-level permissions.
3) Malicious File Execution. This flaw covers a variety of problems in which hostile code can navigate the file system to get access to resources, as well as provide input files with malicious content. The application is susceptible to this flaw if it accepts either files or file names from users.
4) Insecure Direct Object Reference. Modern object-oriented platforms depend extensively on object references. Often only the instantiation of the object is secured, so that, once the object exists, it can be used in any way. This flaw arises when you inadvertently expose a reference to an otherwise secure object, putting its resources at risk.
5) Cross-site Request Forgery. This flaw depends on credentials that a browser automatically supplies with a Web request, such as cookies, authentication credentials, IP addresses, and SSL certificates. It causes a browser to send a request to the Web application, which, because the user is logged in, successfully executes.
6) Information Leakage and Improper Error Handling. This is really two flaws. ASP.moldy was infamous for information leakage, displaying by default lots of internal details when an unhandled exception arose. An attacker can use that information to simplify the process of finding resources to attack. With improper error handling, you can inadvertently allow malicious code to circumvent security measures, such as by allowing actions in an exception block many levels away from the actual source of the error.
7) Broken Authentication and Session Management. This flaw arises when authentication credentials and session tokens are not protected. Often the source of the problem are cookies that are not protected. This makes it easy to hijack user accounts.
8) Insecure Cryptographic Storage. Insecure Cryptographic Storage is probably not the most descriptive name for this flaw. It covers situations where sensitive data is either not encrypted either when stored or on the move across the network or there is some flaw in the encryption. The latter could arise from a poorly chosen algorithm, insecure key storage, or other well-known problems with cryptography.
9) Insecure Communications. It is all too easy to focus on security on the server but ignore security once data leaves the server. This flaw arises because applications often don t encrypt network traffic, such as SSL. At the very least, it is critical to encrypt all authentication traffic between client and server and between servers as well as any tokens passed with each Web request. In this day and age, it is hard to envision a Web application involving sensitive information that does not encrypt all network traffic.
10) Failure to Restrict URL Access. This flaw involves security by obscurity. Many Web applications attempt security by not showing links to unauthenticated users. The links themselves, however, are not protected in any way. An attacker can discover those links in myriad ways, such as when na ve users share them or they are discovered in a browser cache. There is no substitution for access checks for all sensitive pages.
What s scary about the list is how many flaws arise from trusting user input. If you are not validating every byte of input from your users, your application is almost certainly riddled with nasty security holes.
The nice thing about the OWASP Top 10 list is that the section covering each flaw describes the flaw, the most common situations and technologies where it arises, and how to mitigate the flaw to protect yourself against them. There is also a description of the methodology used to compile the list, suggestions about what to do about the flaws, and some recommendations for reading up on them. The online version of the list is in a wiki, so over time the descriptions are likely to only get better with everyone s help.
A good understanding of the OWASP Top 10 can go a long way toward helping you develop secure Web applications.
Don Kiely, MVP, MCSD, is a senior technology consultant, building custom applications as well as providing business and technology consulting services. His development work involves tools such as SQL Server, Visual Basic, C#, ASP.NET, and Microsoft Office. He writes regularly for several trade journals, and trains developers in database and .NET technologies. You can reach Don at mailto:[email protected] and read his blog at http://www.sqljunkies.com/weblog/donkiely/.
