Levels of Security
for Web Applications
Access Control
The AltaVista firewall secures the internal network by limiting and controlling Internet access. The only internal server Internet users can access is the Web Application Server. Furthermore, the firewall only allows users access to this server via HTTP which eliminates potential security breaches.
The Web Application Server should be placed in the internal network (BLUE zone). This becomes more obvious when examining the security threats if it is placed in either the external network (RED zone) or the DMZ (GREEN zone). If the server is placed on the external network (RED zone), several different types of security breaches become possible. First, the server is not protected from various types of TCP/IP hacks. If the server becomes compromised, it can then become the "base" for trying to hack the internal network. Also, the Web Application Server communicates with the internal servers via unencrypted usernames, passwords, etc. This can become a theat if someone is able to install a network "listener" on the external network. Furthermore, if the Web Application Server is placed on the external network, the firewall has to be opened up to allow various non-standard TCP/IP communication to pass.
The DMZ (GREEN zone) should only be used for "self-contained" servers. In other words, servers in the DMZ should not be allowed to initiate communication with the internal network. If servers in the DMZ were compromised, they could pose a threat to the internal network if allowed to initiate communication.
Placing the Web Application Server in the internal network provides the greatest protection for both the server itself and other servers on the internal network. The server is protected against most Denial of Service attacks, and "trogan horse" hacks. Allowing only HTTP traffic access to this server does not provide potential hackers with enough leverage to gain access to the internal network.
Authentication
Most Web applications need to be secured. Anonymous users should not be allowed access to business critical applications. Users need to be forced to prove their identity before gaining access. This is the process of authentication. Web developers have to port thier client/server authentication routines to the Web. This is usually done by displaying a logon page before users are allowed to use the Web application.
The Web (actually the HTTP protocol) presents a greater challenge in terms of authentication in that HTTP is a state-less protocol. In the typical client/server paradigm, once a user logs in, a session is created and the user remains authenticated for the duration of the session. However, a HTTP session only lasts for one request. Therefore the Web application has to maintain session information by using some sort of token that is passed with every request/response. This is usually done either via cookies or URL remapping.
There are a few other ways to authenticate users. First, you can use operating system user accounts. To do this, the Web server is set not to allow anonymous access. Operating system user accounts need to be set up for all Web application users. The Web application needs to be able to access operating system user account information. Another way to implement security is by using PKI (Public Key Infrastructure). All Web application users are issued keys. All packets originating from users are "signed" with their individual key. PKI provides the greatest level of security. However, implementing PKI at this time is both extremely costly and time consuming.
Autheticating users via a "logon page" mechanism provides many benefits over these other mechanisms. It is the quickest to implement when porting "legacy" applications to the web because user account information is already stored in the application. It provides the greatest flexability because different levels of user access can be provided. Excessive user accounts do not need to be created, which could become a security threat. Furthermore, when this mechanism is implemented with encryption, it can provide a high enough level of integrity for all but the most secure applications.
Encryption
Encryption is the other half of picture when it comes to securing Web applications. Encryption provides confidentiality. Data is protected from being read, copied or altered by anyone who is not expicitly authorized to do so. This type of security protects both the username and password that the user uses to authenticate, and the data that is passed back and forth between the user and the application.
Encryption is typically implemented in Web applications via SSL (Secure Sockets Layer) and HTTPS. Serveral steps need to take place to implement SSL. First you need to get a public/private key pair from a registered certificate authority. The most well known is Verisign. Once you receive this key, you can then specify which directories the Web server should encyrpt. For a Web application, you specify the virtual directory from which the application exposes itself. All Web directories can be encrypted if necessary.
Once these three layers are in place, a Web application can provide a greater level of services to users while maintaining the security business critical applications require.