X
Tech

Web Design: An Introduction to Web Application Security Frameworks

The Internet is a pretty big place. Not only that, but when you create a Web site, anyone with a browser can call it up.
Written by Thomas Ortega, Contributor

The Internet is a pretty big place. Not only that, but when you create a Web site, 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 (WASF) 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.

Web sites need security for a lot of reasons, but 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 is 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, it's also the least secure because someone could simply continually try different username and password combinations. With today's powerful processors, 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 of "life or death" importance, so this simple 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, decide whether or not to let you in?" Not quite.

Inherently, operating systems have security built into them. Whether it's a login/password for the machine or login/password for the network the machine is connected to, users can identify themselves to be granted certain permissions. The reasoning behind using this security for Web applications is that if you already have a database of logins and passwords, why do should you 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 visits 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 set up 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 found on intranets.

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 that anyone who wanted to could listen in and steal it. In response to this concern, 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 (that is, 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 information from unsuspecting Web users. The Web clients (that is, the browsers) don't have certificates installed. Instead, Amazon assumes that by providing a valid name and password, you're who you say you are.

To achieve absolute security, the Web client could install a digital certificate on its machine. This would then prove with absolute surety that 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 the 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.

Options
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. The final article in the series will be explore 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?

Builder.com originally published this article on 26 November 2003.

Editorial standards