Web application security frameworks, part 1: Introduction

Often you will want parts of your Web application to be exclusive to certain users. This access distinction requires the use of Web application security frameworks. This first article in the series introduces you to the three most often used methods.

The Internet is a pretty big place. Not only that, but when you put a Web site up, anyone with a browser can call it up. That's the beauty of the Internet, right? It is so long as you want everyone to access every part of your Web site. What happens when you don't want to let the world in?

Web Application Security Frameworks provide a way to limit access to your Web site. There are many ways you could set up security, but the three most often used are: database lookup, OS level authentication, and digital certificates.

Series information
This article is the first in a series of five. In the first article, I give a brief overview of the three main types of web application security frameworks. I'll then spend an article on each type. Finally, I'll wrap it all up with an article going over everything we've learned and remind you of when to use each type.

The reasons for needing security in a Web site are numerous. What they all boil down to is this: You want to make sure that certain content is only seen by certain people. It's a dilemma that is older than the Internet, but luckily some smart people have developed ways to accomplish this online.

Database lookup
One of the easiest ways to implement security is by using a database lookup. Now, by database, I'm not necessarily talking about an RDBMS such as Microsoft's SQL Server or Oracle. Instead, the following definition is what I mean: an organized body of related information. Whether the body of information is very complex with over 75 attributes per user, with roles and multiple group memberships or it's as simple as a two fields per user, the data needs to be there for us to check against.

There are many ways to carry out the lookup, and the method you use will largely depend on the storage method you're using. If you're using LDAP, you'll use an LDAP call. If you're using an RDBMS, then you'll likely use a connector such as ODBC. If you hard code the data in the application, then you'll just check against those values.

I would venture to say that most Web applications utilize this method for authenticating their users. The telltale sign is the ubiquitous form that consists of two fields (username/login and password) and a submit button. The form sends those two fields back to the server. The server then checks those fields against its database. If the lookup fails, the user is impeded and can go no further. If the lookup is successful, then the user is directed to the appropriate content that otherwise is not visible to the Internet at large.

This method is the easiest to implement of the three mentioned here. However, because of its ease of implementation, it is the least secure. The reason for this is that someone could simply continually try different username and password combinations. With processors being so powerful today, it would just be a matter of minutes (if not seconds) before a usable combination could be found using a script. Most of the time though, the content behind the security framework isn't "life or death" important, so this methodology works out just fine.

OS level authentication
The next security type is OS level authentication. Some of you maybe asking, "So, what does this mean? Does it check what type of operating system you're running and based on that, decides whether or not to let you in?" Not quite.

Inherently, operating systems have security built into them. Whether it is a login/password for the machine or login/password for the network the machine is connected to, there is the ability for the users to identify themselves to be granted certain permissions. The reasoning behind using this security for Web applications is this: We already have a database of logins and passwords, why do we need to create another?

Obviously, this type of security will work only if the users have been identified and set-up by an administrator prior to their visit to the Web site. While this may work for tight knit groups such as business corporations or professional organizations, it won't work for high volume Web sites. For example, could you imagine if Amazon had to centrally manage each and every one of its customers? It wouldn't work. However, for corporations, security administrators already do setup each user account, so there's an opportunity to reuse that information. Therefore, the Web applications that benefit from this type of security are primarily intranet-based ones.

Digital certificates
Back when Netscape kicked off the whole Internet craze, people realized that we were going to need a way to secure our communications. Otherwise, no one would feel comfortable sending or receiving sensitive information knowing anyone who wanted to could listen in and steal the information. Therefore, digital certificates were born.

Digital certificates provide a mechanism to encrypt and decrypt data. When you hear the term SSL, or see a URL switch from http:// to https://, you're using digital certificates. For the most part, digital certificates are only used on one side of the Web conversation. The Web server, i.e. the Web site, has the certificate installed to help verify that it is who it says it is. Otherwise, any Web site could pretend to be Amazon and harvest credit card info from unsuspecting Web users. The Web clients, i.e. the browsers, do not have certificates installed. Instead, Amazon assumes that by providing a valid name and password, you are who you say you are.

To achieve absolute security, the Web client could install a digital certificate on their machine. This would then provide with absolute surety you are who you say you are. If that's the case, why don't we? There are a few reasons. First, and foremost, is cost. Digital certificates cost a few hundred dollars a piece; not exactly something the average Web user is going to pay for. Next is portability, or lack of it. The certificate must be installed on the machine level. Who is going to want to install a certificate on every machine they want to use to shop on? Lastly, it has to do with laziness. Let's face it. Web users are a lazy lot. If it takes too long, they won't do it. If you need absolute security though, then they're more likely to submit to a method such as this.

As you can see, there are a few options to choose from when it comes to WASF. Obviously, this is just a quick overview of the three major types. In the upcoming articles, we will be analyzing each type in detail. The first one will go over the database lookup type. Following that article will be a piece on OS level authentication. Lastly will be the piece on digital certificates. Each article will go in detail to answer the three following questions: What is it? How does it work? How is it implemented?

Editor's Picks