The Open Web Application Security Project’s Top 10

Secure ASP.NET

The Open Web Application Security Project s Top 10

By Don Kiely

The OpenWeb Application Security Project (OWASP) is an interesting communitydedicated to making Web applications more secure. It has a wealth of resourcesthat can help you develop, purchase, and maintain secure applications. At anygiven time it has a few dozen projects of various types, such as requirementsand metrics, education, tools, and honeycomb projects, spanning all platformsand technologies including .NET. If you are concerned about the security ofyour Web applications and aren t familiar with OWASP, I suggest you exploretheir Web site now.

One of their more interesting and ongoing projects is theOWASP Top 10 Project. Updated every few years to stay representative toevolving threats, the list represents a consensus of the most critical Webapplication security flaws. Although it is completely devoid of the humor of aLetterman Top 10 List, OWASP s list is useful in myriad ways. If you re adeveloper, it s a great resource for making sure you have the skills to createsecure Web sites. If you re an organization with a Web site, it can form thebasis for a security review of the site to identify security problems. It isn ta panacea, but, because it represents the most prevalent threats on the Webtoday, 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 ismy summary of the list:

1)     Cross-site Scripting. This is one ofseveral classes of attacks that embeds code in data.Attackers can cause script to execute in a browser with all sorts of nastyconsequences.

2)     Injection Flaws. It s a bad sign thatthe first two items on the list take advantage of code as data. The most commonversion of this type of flaw is SQL injection, where hostile commands executeas part of SQL statements. Probably the biggest problem here is that thehostile code executes with the permissions of the application, which all toooften are administration-level permissions.

3)     Malicious File Execution. This flawcovers a variety of problems in which hostile code can navigate the file systemto get access to resources, as well as provide input files with maliciouscontent. The application is susceptible to this flaw if it accepts either filesor file names from users.

4)     Insecure Direct Object Reference.Modern object-oriented platforms depend extensively on object references. Oftenonly the instantiation of the object is secured, so that, once the objectexists, it can be used in any way. This flaw arises when you inadvertentlyexpose a reference to an otherwise secure object, putting its resources atrisk.

5)     Cross-site Request Forgery. This flawdepends on credentials that a browser automatically supplies with a Webrequest, such as cookies, authentication credentials, IP addresses, and SSLcertificates. 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 ErrorHandling. This is really two flaws. ASP.moldy was infamous for informationleakage, displaying by default lots of internal details when an unhandledexception arose. An attacker can use that information to simplify the processof finding resources to attack. With improper error handling, you caninadvertently allow malicious code to circumvent security measures, such as byallowing actions in an exception block many levels away from the actual sourceof the error.

7)     Broken Authentication and SessionManagement. This flaw arises when authentication credentials and sessiontokens are not protected. Often the source of the problem arecookies 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 forthis flaw. It covers situations where sensitive data is either not encrypted eitherwhen stored or on the move across the network or there is some flaw in theencryption. The latter could arise from a poorly chosen algorithm, insecure keystorage, or other well-known problems with cryptography.

9)     Insecure Communications. It is all tooeasy to focus on security on the server but ignore security once data leavesthe server. This flaw arises because applications often don t encrypt networktraffic, such as SSL. At the very least, it is critical to encrypt allauthentication traffic between client and server and between servers aswell as any tokens passed with each Web request. In this day and age, it ishard to envision a Web application involving sensitive information that doesnot encrypt all network traffic.

10) Failure to Restrict URL Access. Thisflaw involves security by obscurity. Many Web applications attempt security bynot showing links to unauthenticated users. The links themselves, however, arenot 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 fromtrusting user input. If you are not validating every byte of input from yourusers, your application is almost certainly riddled with nasty security holes.

The nice thing about the OWASP Top 10 list is that thesection covering each flaw describes the flaw, the most common situations andtechnologies where it arises, and how to mitigate the flaw to protect yourself against them. There is also a description of themethodology used to compile the list, suggestions about what to do about theflaws, and some recommendations for reading up on them. The online version ofthe list is in a wiki, so over time the descriptions are likely to only getbetter with everyone s help.

A good understanding of the OWASP Top 10 can go a long waytoward helping you develop secure Web applications.

DonKiely, MVP, MCSD, is a senior technology consultant, building customapplications 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 readhis blog at http://www.sqljunkies.com/weblog/donkiely/.