11.1 Web Security

Security is often one of the last issues addressed by developers. It requires thinking about your applications in a different light from what you are accustomed to. As you build your applications, your goal is to make them as useful and easy to use as possible. When you consider security, however, the goal is often quite the opposite . You find yourself asking questions such as "How can I be sure that these people cannot access this portion of my application?" or "How can I validate that the request coming into my application is from who I think it is, and not some person pretending to be someone else?"

With Web applications, the issues of security are magnified because almost all communication to and from the application is performed across long connections. For this reason, one of the most important security issues in Web applications is authentication. Clients want to know whether the site they are looking at is indeed produced by the company it purports to be from, and servers often need to know the identity of a particular client, especially if the application is modifying data on behalf of a client (as with a bank account). The level of security required is very application dependent. Web applications that are simply informative may not care about client credentials and are happy to deal with all clients as anonymous users. Web applications that provide customized content may want to identify clients only if they want to be identified (for customization), and are otherwise happy to let anonymous clients browse the application at their leisure. Web applications that provide client services (stock portfolios, bank accounts, and so on) typically need to be much more careful about client identity and often require client authentication before any pages on the site can be displayed.

As a Web application developer, you must be aware of the level of authentication required by your application and add only the security services necessary. Each additional security requirement of your application makes it more complex and may have significant impact on its design.

11.1.1 Server Authentication

Server authentication is often very important to clients. They want to be sure that the Web site they are viewing is in fact being published and run by the authority it claims to be. This is especially true if a client is sending sensitive information, such as credit card or bank account numbers , to the server. If the server has not somehow authenticated itself with the client, the client cannot be sure that someone is not surreptitiously pretending to be that site just to collect information from clients.

Authenticating servers in a well-controlled local network is a solved problem. A particular machine is designated as the domain controller and takes responsibility for validating that each communication is authentic . Protocols such as Kerberos work well in this environment. As soon as we try to scale these techniques to the Web, however, we quickly run into client firewall constraints that make it impossible to exchange secret keys safely.

One solution to this is to use a technology labeled digital certificates . Digital certificates rely on public key cryptography that lets servers maintain a private key and publish their public key, which clients can use to authenticate that the server is indeed who it says it is. There is still a problem, however; someone may intercept the sending of the public key and replace it with his own. The person in the middle who swapped in his own public key can then potentially intercept and modify subsequent communication between that client and the server.

The solution to this is to designate a trusted authority that can vouch for the public keys of anyone that registers them with this authority. Companies (such as Verisign) have set up such a system and, for a fee, will store and vouch for your public key. As long as everyone trusts that the third-party company is telling the truth, and clients make the effort to verify server certificates, digital certificate authentication of servers works reasonably well. The one issue remaining is how to verify that the third party is who it claims to be (how do you know that Verisign is in fact the one performing the verification of a public key?). Distributing the public keys of companies like Verisign with browser installations solves this.

11.1.2 Client Authentication

With server authentication, there is little question about the purpose of the authentication. It is always to guarantee the identity of the server to the client. Client authentication, on the other hand, can be used for several different purposes. Some Web sites need to authenticate clients so that they can customize their content based on the preferences of those clients (for example, an e-commerce site may want to display on the front page items it thinks you will purchase when you visit it). Other sites control access to all or portions of the site based on client identity. Finally, some sites require that clients have credentials on the server (Windows logins) so that operations performed through the Web site can be done with the credentials of the client (very common with intranet applications). Each of these types of client authentication requires different levels of assurance and can be implemented in several ways.

Through IIS, you can specify the level of client authentication to use for a given Web application (or a page within an application). By default, IIS prefers not to perform client authentication because it will incur more server involvement with each request, slowing down the system. If no client authentication is selected (Anonymous), every request is treated as anonymous, and a designated account (IUSR_ MACHINE , where MACHINE is the name of your machine) is used for credentials. To force client authentication with IIS, you can disable anonymous access and then choose one of the available client authentication methods . Figure 11-1 shows the IIS configuration form controlling client authentication for a virtual directory.

Figure 11-1. IIS Client Authentication Settings

The options for client authentication in IIS are Basic authentication, Integrated Windows authentication, and Digest authentication. Basic authentication requires that the client pass his password as clear text, which makes sense only if it is being encrypted, thus the use of Basic authentication is typically restricted to sites using SSL as their protocol. Even with the password being encrypted, however, it is still available to scripts within the Web application through the AUTH_PASSWORD intrinsic variable, which may not be something you want.

Integrated authentication attempts to use native Windows authentication. This works by negotiating Kerberos or NTLM with proprietary extensions to HTTP, and works only for clients running IE who have a valid account on the server and who are not separated from the server by a firewall or proxy, because Kerberos is typically inhibited by a firewall, and NTLM becomes nonoperational through a proxy. This option may be useful for local intranets , but is typically much less useful for Internet servers.

Digest authentication uses a challenge/response technique to verify a client password. This means that the password must be available on the server, and thus the server must be a domain controller on the server network, which is usually not advisable, because having someone hack into your domain controller could be disastrous. It is also possible to configure IIS to accept client certificates for authentication. Certificate authentication is similar to the certificate authentication used to authenticate servers, but the server requests a certificate of the client instead of the other way around. For this to work, all clients must have valid certificates to present to the server to gain access to the site, as well as the server requiring a valid certificate.

In general, a large percentage of Windows-based Web applications do not rely on IIS to perform client authentication because it requires that clients do something special (obtain a server account or a certificate, for example), and most sites want to allow as many users access as possible. Instead, these sites typically authenticate clients at the application level and manage the details of keeping passwords and accounts themselves . This gives them much more flexibility and control in designing their client authentication system.