Security Requirements
What are the common security requirements for Web applications? As one would expect, these would depend upon the nature of the Web application and whether it is available over the Internet or a behind-the-firewall intranet. The security requirements of a Web application providing weather information or news is likely to be much less stringent than a Web application that provides an online banking service.
A practical approach is to understand different security requirements in isolation and then decide which ones are relevant for a particular deployment of a Web application.
User Identification and Authentication
Though it makes sense for a number of Web applications, like the ones that furnish weather information or stock quotes and rely on advertisements to cover the cost of operating, to be accessed anonymously, a good number need to know the identity of the user. You certainly wouldn't want your bank account to be accessed by anyone other than you. To make sure that the person providing the identity information is not someone else, the application needs to authenticate the user. In most cases, this happens when the user logs into the application by providing a user name and a password.
The way our sample Web application RMB works right now, any person (or program) can post a message with any name and remove some one else's message. Forget about the Internet, this could be problematic even in a small, close-knit community. No one would trust the relationship between the message and its author. In fact, no one would like to post messages on such a message board. To make the message board trustworthy, RMB needs to maintain a list of valid users, and require users to login before posting messages.
A wide variety of authentication schemes are available for Web applications and supported by J2EE Web containers. These are further discussed under the sections User Authentication Schemes and Web Container Security Features.
User Account Systems
The process of an application authenticating a user based on username and password assumes that the application knows the username and the corresponding password (or is somehow able to confirm its validity) for all its valid users. It is also important to make sure that only the rightful owner knows the password and no one else. There is usually an initial setup phase to accomplish this.
Most applications either maintain their own user account systems or access an existing one. A new user must sign up or register to create a user account and obtain or select a username and password. Most e-commerce sites allow self-registration through the browser itself. They don't really care about your real identity. If there is any tie-in with your real self, it is through the credit card number, and in some cases, an e-mail address where you can receive messages.
A user account management system must take reasonable precautions to make sure that the passwords are not easily guessable and are immune to known attacks such as dictionary attack. It may also implement the policy of mandatory change every few months. In cases where a user forgets his or her password, it should be possible to assign a new password after verifying the identity claim through other means. This process may be automated or may require going through a human operator.
Self-registration over the Internet could make a site vulnerable to denial of service attacks. One or more automated programs could start creating bogus accounts, locking up resources and denying the service to genuine users. A defense against such attacks is to present a camouflaged visual pattern during registration and ask the user to recognize the pattern. Automated programs are usually not good at identifying such patterns.
In some cases, the user may already have an account. This would be the case if your brick-and-mortar bank started offering Internet banking or your employer started offering employee services through Web browsers.
Because of the overhead and inconvenience involved in creating a user account and remembering the corresponding username and password, most websites allow the same user account to be used for all the Web applications belonging to that website. This is made possible through single sign-on systems that maintain the user accounts and interface with different applications for user authentication.
All this implies that a Web application should be able to interface with different user account systems at the time of deployment. This requirement is not directly addressed by J2EE specification but Web containers usually provide a mechanism to accomplish this. We cover the mechanism supported by Apache Tomcat to hook up with an external user account system in a subsequent section.
Authorization
A Web application may choose to restrict certain users from carrying out certain operations. In other words, a user is able to perform only those operations for which he or she is authorized. In our sample Web application RMB, it may be okay for any authenticated user to post a message but only the user that posted a message should be allowed to remove it. More complex authorizations are possible—a Web application providing an interface to human resource processes would allow a manager to look at salary information of his or her direct reports but not others.
A limited degree of authorization is possible by restricting access to specific URLs or collection of URLs based on the user roles. It is also possible to limit the access to specific HTTP methods such as GET, POST, PUT, DELETE, and so on. Such authorization rules can be specified in the deployment descriptor of the Web application.
Some of the authorization rules may require knowledge of application-specific entities and it may not be possible to specify them in a deployment descriptor. A different approach, one involving active participation of the logic of the Web application, is required for specification and enforcement of such authorization rules. We learn more about this in the Web Container Security Features section.
Server Authentication
Users typically rely on the domain name of the server running a Web application to ensure that they are interacting with the genuine site and not a fake one. However, this doesn't provide adequate assurance if the network elements routing your data packets are not trusted. A compromised DNS server can very easily connect you to a different machine, even if you specify the right URL in the address field of your browser.
The solution is to let the server authenticate itself with a X.509 certificate. As we know, SSL does exactly this.
A J2EE-compliant Web container must support SSL. Use of SSL can be specified for specific URIs by suitably modifying the Web application deployment descriptor. The specifics of this configuration are covered in the section Web Container Security Features.
Message Integrity and Confidentiality
Certain sensitive interactions between a browser and the Web application, especially those carrying username and passwords, credit card numbers, or other such private information, must ensure that the data has not been observed by a snooper or altered during exchange. This guarantee of message integrity and confidentiality should be possible even if the network elements routing the data traffic themselves are compromised.
Such end-to-end message protection is possible with SSL. However, as we have already seen in Chapter 6, Securing the Wire, SSL comes with a price in the form of slower response time and more hardware for processing the same number of requests. Given that, one should use SSL only for those interactions where message integrity and confidentiality is important.
There may also be a need to ensure the integrity and confidentiality of certain type of data elements stored on the secondary storage. The purpose is to safeguard the data and minimize the damage if the machine itself gets hacked into. It may also help in protecting sensitive data from those responsible for administering the machines and applications. Such protection is possible through cryptographic means. Data can be encrypted to ensure confidentiality and MAC can be computed to ensure integrity. It is becoming common to protect access log files against tampering using message digest or MAC.
Due to increased complexity and performance overhead, the practice of protecting data on secondary storage is not very common.
Audit Logs
Audit logs provide security-relevant information about usage of a particular Web application and are useful for a number of reasons:
They can provide individual accountability.
They can provide insight into user behavior while using the Web application.
They can help spot suspicious activity.
They can reconstruct sequence of events after a break-in has happened, leading to identification of the culprit.
They can be useful in legal proceedings to prove wrongdoing.
As mentioned earlier, audit logs should be tamper-proof in a high security environment so that the attacker is not able to modify the log records to cover up his or her actions. This is also a requirement if the log is to be used in legal proceedings.
It is often not clear what needs to be logged as part of audit logs. Like a lot of other security policy decisions, this one is also usually made at the time of deployment. As a high-level guideline, it should be possible to enable logging of network activity, HTTP request and responses, authentication events, authorization requests, account management functions, and so on. A Web container like Apache Tomcat already has a provision to log a wide variety of events, which can be selectively enabled.
At times, there may also be a need to log data by the application and be able to correlate the data to lower-level events such as network activity, HTTP data exchange, authentication, and authorization activities.