| Security is a goal that spans every tier and layer. To ensure a comprehensive security solution, best practices must span these tiers and layers as well. This section contains a summary of best practices that should be applied to the Web tier. They are categorized loosely by layer. Not all of them pertain specifically to the patterns outlined in this chapter, but they do pertain to securing the Web tier and therefore should be used in conjunction with the Web tier security patterns. It is important to remember that deficiencies in one layer may invalidate all the other efforts in the other layers. An attacker only needs one hole to compromise the application. You can harden the operating system, construct a DMZ, use SSL, and audit every transaction, but if an attacker can guess an administrator's passwords, these efforts were in vain. Take care to review all of the following best practices to ensure a cohesive security approach. Infrastructure Put Web Servers in a DMZ. Secure the Internet-facing Web server host in a DMZ (Demilitarized Zone) using an exterior firewall. It is always a recommended option to use DMZ bastion hosts or switched connections to target Web servers. This will prevent attackers who have compromised the Web server from penetrating deeper into the application. Use Stateful Firewalls. Use a stateful firewall inspection to keep track of all Web-tier transmissions and protocol sessions. Make sure it blocks all unrequested protocol transmissions. Drop Non-HTTP Packets. Make sure your firewall is configured to drop connections except for HTTP and HTTP over SSL. This will help prevent Denial of Service (DoS) attacks and disallow malicious packets intended for back-end systems. Minimize and Harden the Web Server Operating System. Make sure the operating system that is running the Web and application server is hardened and does not run any unsolicited services that may provide an opening for an attacker to compromise. Secure Administrative Communications. Make sure all administration tasks on the server are done using encrypted communication. Disable remote administration of Web and application servers using system-level and root administrator access. All remote administration needs to be carried out using secure-shell connections from trusted machines and disallow administrator access from untrusted machines. Disallow Untrusted Services. Disable telnet, remote login services, and FTP connections to the server machines. These are commonly attacked services and represent a strong security risk. Check Web Server User Permissions. Make sure the running Web and application servers' configurations and their user privileges have no rights to access or to modify system files. Disable CGI. Unless required, disable running CGI applications in the Web server or application server and accessing /cgi-bin directories. This is another common source of attacks. Enforce Strong Passwords. Change all default passwords and use robust password mechanisms to avoid password-related vulnerabilities such as sniffing and replay attacks. For all application-level administrators, use password ageing, account locking, and password-complexity verification. Using one-time password mechanisms, dynamic passwords that use challenge-response schemes, smart card- and certificate-based authentication, and multifactor authentication are reliable practices. Audit Administration Operations. Limit all Web administration access to the system to very few users. Monitor their account validity, log all their administration operations using encryption mechanisms, and make sure that system log files are written to a different machine that is secure from the rest of the network. Check Third-Party IPs. All third-party supporting applications that are required to coexist with the Web and application servers have to be tested for their usage of IP and port addresses. Those applications must follow the maintained rules of the DMZ. Monitor Web Server Communications. Monitor all transmissions and Web-server requests and responses for suspicious activity and misuse. Use watchdog macros or daemons to monitor and trap these activities. When detection of such abuses occurs, make sure you check the integrity of the application afterward and notify the system security administrator. Setup IDS. Use intrusion detection systems to detect suspicious acts, abuses, and unsolicited system uses. Alert security administrators for such activities. Deny Outbound Traffic to Web Server. Disallow all application requests to the IP addresses of the Web servers running in the DMZ. Distrust Servers in the DMZ. Do not store any user or application-generated information in the DMZ. Store all sensitive information behind the DMZ interior firewall with the expectation that servers running in the DMZ will eventually be compromised. The exception would be a Honeypot, which is a server created specifically to lure attackers into what appears to be the real application. Their activities are then logged and analyzed to help stave offd future attacks.
Communication Secure the Pipe. For all security-sensitive Web applications and Web-based online transactions, make sure the session and data exchanged between the server and client remain confidential and tamper-proof during transit. SSL/TLS is the de facto technology for securing communication on the wire. It allows Web-based applications to communicate over a secure communication channel. Using SSL communication with digital certificates offers confidentiality and integrity of data transmitted between the Web applications and client authentication. Segregate by Sensitivity. Make sure that Web applications that contain sensitive information and Web applications that do not contain sensitive information run on different machines and different Web-server instances. Enforce Strong Encryption. For applications that use classified or financial data, make sure that the Web server does not accept weak encryption. Disable or delete weak encryption cipher suites from the Web server and enforce adequate key lengths. Don't Flip Back to HTTP from HTTPS. After switching to SSL communication, make sure the application no longer accepts non-SSL requests until logging out from the SSL session. In the event that the client is sending a non-SSL request, the application must enforce reauthentication of that user over a new SSL session and then stop listening to non-SSL requests. Verifying SSL requests can be implemented using various Connection filter mechanisms. Capture Bad Requests. Log and monitor all fake SSL and non-SSL requests using filters. For all such unsolicited requests, redirect the user to an authentication page to provide valid login credentials. Use Certificates for Server-to-Server Communications. To support server-to-server or nonbrowser-based client communications that host secure transactions, always suggest using mutual or client certificate-based authentication over SSL. In this case, the server will authenticate the client using the client's X.509 certificate, a public-key certificate that conforms to a standard that is defined by X.509 Public Key Infrastructure (PKI). This provides a more reliable form of authentication than standard password-based approaches. Check Mutual Authentication. Verify that mutual authentication is configured and running properly by examining debug messages. To generate debug messages from SSL mutual authentication, pass the system property javax.net.debug=ssl,handshake to the application, which will provide information on whether or not mutual authentication is working. Check Certification Expiration. While authenticating a client using mutual authentication, be sure to check for certificate expiration or revocation. User SSL Accelerators. Using hardware-based SSL accelerators enhances secure communication performance because it offloads the cryptographic processing load from the Web server. Use SGC When Possible. Consider using Server Gated Cryptography (SGC) mechanisms when possible to ensure the highest level of security for Web applications regardless of browser clients or versions. Check Export Policies. Before installing SSL server certificates, make sure that you understand and are in accordance with your country's export policies regarding encryption products containing cryptographic technology. Some countries and organizations may ban or require special licenses for using encryption technologies.
Application Disallow Direct Access. Make sure that the application resides on a server accessed via reverse-proxy or Network Address Translation (NAT)-based IP addresses. Then rewrite the URLs of Web applications. This protects the application from direct access from unsolicited users. Encrypt Application-Specific Properties. Make sure that all application-specific properties stored on local disks that are exposed to physical access are encrypted or digested using encryption or secure hash mechanisms. Decrypt these entries and verify them before use in the application. This will protect unauthorized access or modification of application-specific parameters. Restrict Application Administrator Privileges. Do not create an application administrator user account (that is, admin or root) with explicit administration access and privileges. If someone steals the administrator's password and abuses the application with malicious motives, it is hard to find out who really abused the application. Use the security Principal of the user and assign role-based access by assigning users to the administrator role. This helps in identifying the tasks carried out by the associated Principal with an administrator role. Validate Request Data. Verify and validate all user requests and responses and inbound and outbound data exchanged with the application. Apply constraints and verify the input data so that the data does not cause any undesirable side effects on the application. Validate Form Fields. Ensure that any alteration, insertion, and removal of HTML form fields by the originating browser are detected, logged, and result in an error message. Use HTTP POST. Use HTTP POST rather than HTTP GET and avoid using HTTP GET requests while generating HTML forms. HTTP GET requests reveal URL-appended information, allowing sensitive information to be revealed in the URL string. Track Sessions. Identify the originating user and the host destination making the application request in the sessionid. Verify that all subsequent requests are received from that same user's host origin until the user logs out. This protects application sessions from hijacking and spoofing. Obfuscate Code. Obfuscate all application-related classes to avoid code misuse. This protects the code from being easily reverse engineered. This should be done for stand-alone Java clients, helper classes, precompiled JSPs, and application JAR files. Sign JAR Files. Make sure that all JAR files are signed and sealed before deployment. This includes signing JNLP files (Java Web Start), signed applets, and signed JARs for application server deployments. Audit All Relevant Security Tasks. Securely log, audit, and timestamp all relevant application-level events. Audit events should include login attempts and failures, logouts, disconnects, timeouts, administration tasks, user requests and responses, exceptions, database connections, and so forth. Redirect the log data to a file or database repository residing in another machine. Logging and auditing help to track and identify users with malicious intentions. Audit All Relevant Business Tasks. Create audit trails for all identified user-level sessions and actions with timestamps and store them in a different log file with unique line identifiers. This helps in achieving nonrepudiation in both business and technical aspects of the application. Destroy HTTP Sessions on Logout. Once a user logs out or exits a security-sensitive application resource, invalidate the HTTP Session and remove all state within the session. Leaving stale sessions on the server often leads to security breaches involving session hijacking, client-side Trojan horses, and eavesdropping on subsequent sessions. Set Session Timeouts. Use HTTP session timeouts for all user sessions after a period of inactivity. Redirect the user back to the login page for reauthentication to enable the stored HTTP session state.
|
