Summary

Web applications accessible over the Internet are an attractive target for cyber attackers. Use of the Internet for business-critical operations and financial transactions implies that a successful attack could be quite rewarding for an attacker. The open nature of the Internet and the relative anonymity provided by it offers added incentive.

A J2EE Web application is a collection of servlets, JSPs and other configuration and resource files and is deployed in a Web container. Servlets, JSPs and other related standards provide the framework to develop and deploy Web applications. The Web container itself provides the functionality of a Web server and the Servlet API provides an intuitive and efficient framework to develop application logic.

Most security policies for Web applications are specified declaratively in the deployment descriptor and enforced by the Web container. These policies include specification of user authentication mechanism, access control of URI space based on user role and use of SSL for data confidentiality and integrity. These policies can be specified at the deployment time and are not tied to the application code. Further control can be achieved by using programmatic access control, though it may make security policies more tightly coupled with the application logic.

A number of user authentication technologies are available for Web applications. Two of the authentication mechanisms, HTTP Basic authentication and HTTP Digest authentication, are specified by the HTTP protocol and are managed by the browser and Web container. FORM-based Authentication allows the application to control the authentication process, including look and feel, timing and other aspects of the login prompts. With HTTPS, one could also use a private key and the corresponding X.509 certificate for client authentication.

HTTPS or HTTP over SSL addresses a wide variety of Web application security issues. Use of HTTPS by a website can provide a reasonable assurance to a user, based on a X.509 certificate issued by a reputable CA, that he or she is using the site of a particular organization and not a fake one. HTTPS also keeps the data confidential and tamper-proof as it flows through untrusted network elements. This property makes HTTPS perfect for the exchange of FORM-based authentication data and other such sensitive information. However, it is important to keep in mind that HTTPS protects data only when it is being exchanged and not when it is stored at the either end.

A number of security specific configurations and mechanisms are not addressed by J2EE standards and depend upon Web container implementation. Examples are: parameters related to HTTPS connections; mechanism to plug-in a third-party user account management system; parameters related to audit log, and so on. This chapter covered these specifics for the open source Web container Apache Tomcat. If you are working with a different system, refer to the relevant documentation for details.

Certain programming practices can cause exploitable vulnerabilities. These vulnerabilities are possible even though a system is properly configured for secure operation, requires user authentication, has appropriate access control rules in place, and uses HTTPS for sensitive information. The best way to avoid these vulnerabilities is to make sure that the applications do not use unsafe programming mechanisms as outlined in the Common Vulnerabilities section of this chapter.