13.3 Other Security Concerns

In this chapter we have discussed only authentication and access control, but there's a lot more to web application security. You also need to ensure that no one listening on the network can read the data. In addition, you need to consider ways to verify that no one has hijacked the data and modified it before it reaches its final destination. Common terms for these concerns are confidentiality and data privacy for the first, and integrity checking for the second.

On an intranet, users can usually be trusted not to use network listeners to get to data they shouldn't see. But on the Internet, you can make no assumptions. If you provide access to sensitive data, you have to make sure it's protected appropriately. Network security is a huge subject area and clearly not within the scope of this book. Therefore I will touch only on the most common way to take care of both confidentiality and integrity checking, namely the Secure Socket Layer (SSL) protocol.

SSL is a protocol based on public key cryptography; it relies on a public key and a private key pair. Messages sent by someone, or something (like a server), are encoded using the private key and can be decoded by the receiver only by using the corresponding public key. Besides confidentiality and integrity checking, public key cryptography also provides very secure authentication; if a message can be decoded with a certain public key, you know it was encoded with the corresponding private key. The keys are issued, in the form of certificates together with user identity information, by a trusted organization such as VeriSign (http://www.verisign.com/).

Both the browser and the server can have certificates. However, the most common scenario today is that only the server has a certificate and can thereby positively identify itself to the browser. The SSL protocol takes care of this server authentication during the handshaking phase of setting up the connection. If the server certificate doesn't match the server's hostname, the user is warned, or the connection is refused. If the browser also has a certificate, it can authenticate the browser to the server in a more secure fashion than basic and digest authentication.

Even if only a server certificate is used, the communication between the browser and the server is still encrypted. This means that the issue of sending passwords as clear text for the basic and form-based authentication, as well as the application-controlled authentication we developed in this chapter, is nullified.

Most web servers today support server certificates and SSL. When you use HTTP over SSL (HTTPS), the URLs start with https instead of http. Not all applications need the kind of tight security offered by HTTPS, but you should be aware of all security threats and carefully evaluate if the risks of not using SSL are acceptable for your application.