Countermeasures

Countermeasures

Now that you've seen how deadly this type of attack can be, let's take a look at how easily you can prevent such an attack. Numerous countermeasures exist, but simply employing a handful can prevent 99% of all attacks.

Harden the Java Web Server

To harden your Java Web Server, follow these steps (which are ranked by importance).

         Sanitize input. By far the biggest Internet Achilles heel, input sanitization has the potential to bring down even the most secure Web site. You must employ standard sanitizing algorithms when handling input from a user. Review Chapter 1 for technology and language- specific sanitization scripts. If you do it properly, the chances an attacker would be able to apply the preceding technique are almost nil. In the technique demonstrated in this chapter, the Java code sent by the user field to execute code would never be sent through to the HTML file.

         Restrict executables. Whenever possible, remove unneeded executables such as cmd.exe, tftp.exe, and ftp.exe on Windows systems, and tftp and ftp on Unix systems. If you cannot completely remove these executables from your production Web servers, at a minimum you should restrict their access through access control lists. Windows provides NTFS file permissions that restrict who can execute the commands. Unix also has file permissions built into the standard file system that control who can execute which binary.

         Remove installed sample files. Although this step only would have helped prevent the attack against Sun's JWS (because it comes installed with the bboard servlet), it is a good overall recommendation.

Other Conceptual Countermeasures

Many Java Application servers are plagued by vulnerabilities that arise from oversights in their design and architecture. Although there are no quick countermeasures to such vulnerabilities, you should keep the following conceptual countermeasures in mind.

Isolate System Core Servlets from Application Servlets

The servlet is the core element to a Java application server. Many components of the application server itself are implemented as Java servlets. The core Java servlets are used to retrieve files from the file system, parse input from HTTP requests, compile and execute Java Server Pages, and many more functions. These servlets then form the basis for application development. Whenever an application is deployed on a Java application server, proper precautions should be taken to keep the application servlets separate from the system core servlets. If the application servlets are placed in the same area as the system core servlets, it is possible for attackers to invoke these servlets directly via a servlet invoker, as explained in the section Application Handlers and Invokers.

Prohibit Execution of Unregistered Servlets

A few Java application servers accidentally allow the execution of servlets that aren't registered in the system but are physically present in the servlet classes path. In such cases, even if the system administrator has unregistered these servlets, they still can be invoked if the full path to the servlet is known. The servlet class file has to be physically removed from the file system or the Java archive file in order to prevent accidental execution. Java application server developers should ensure that, if a servlet isn't registered, it shouldn't be allowed to execute.

Bind Servlets to Resource Types

Certain vulnerabilities, such as forcing the JSP handler to compile Java code injected in non-JSP files arise due to the fact that the JSP handler gets applied to resources that are not JSP resources. For example, it should never be possible to apply a JSP handler on an HTML file. The Java application server should have a mechanism to check, restrict, and enforce the application of handlers on various resources.

Validate Input Thoroughly

Input validation is perhaps the single most important countermeasure that we can stress. All input received from the Web browser must be thoroughly checked, especially if it is going to be written to disk or end up in a database at any point.

Disable Direct Application Servlet Invocation

In many cases, application developers prefer to have a URL mapped servlet invoker prefix, such as /servlet/ or /webapp/ to invoke Web application servlets. From a developer's perspective, a URL mapped servlet invoker makes things easy because servlets can be added and removed without going through the hassle of registering them or configuring them individually for invocation. However, from a security point of view, if application and core servlets aren't well segregated, the URL mapped servlet invoker prefix can be used to invoke arbitrary servlets. Good practice, therefore, is to disable direct servlet invokers whenever possible.

Unregister All Unused and Example Servlets

Many times Java application servers ship with example servlets and certain other servlets that don't get used by the java application server. Good practice is to remove physically all example servlets from the file system and unregister core servlets that aren't needed. For example, if the application doesn't use Server Side Includes or Java Server Pages, unregister the SSI and JSP servlets to prevent accidental invocation. Finally, good practice is always to keep the Java application servers updated with the latest vendor patches.

 



Web Hacking(c) Attacks and Defense
Web Hacking: Attacks and Defense
ISBN: 0201761769
EAN: 2147483647
Year: 2005
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net