Table Of Contents

HTTP Error Response Mapping

Mapping HTTP Exceptions

Testing HTTP Exception Mapping

HTTP Error Response Mapping

---

Error messages returned by backend applications (stack traces or other detailed errors) can provide sensitive implementation details that an attacker can use to identify ways to exploit the system. For example, the following listing shows a portion of an exception stack trace returned by a web application:

HTTP ERROR: 500 
INTERNAL_SERVER_ERROR 
RequestURI=/register.do;jsessionid=9htwpf0y943o 
 
 
Caused by: 
 
java.lang.NullPointerException 
	at com.oakinsurance.struts.actions.RegisterAction.execute(RegisterAction.java:44) 
	at org.apache.struts.action.RequestProcessor. 
			processActionPerform(RequestProcessor.java:431) 
	at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) 
	at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) 
	at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) 
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) 
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) 
 
... 
 
	at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:395) 
	at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450) 
 
 
Powered by Jetty:// 

Notice that the error response indicates an internal server error with a status code of 500, along with a stack trace of the Java exception that occurred in the application. This type of stack trace can be helpful for testing and debugging an application, but when allowed to be emitted in a production environment, it provides an attacker with valuable information on backend systems.

By default, the ACE Web Application Firewall allows error messages from back-end applications to pass through unaltered. The HTTP Exception Mapping feature enables you to obscure details of the back-end implementation by returning a generic message in place of the error message from the backend application.

---

Note Instead of concealing information, error mapping can be used to provide additional information to the client on an error, without having to modify the backend system. For instance, you could map a generic "403 Forbidden" response to a 403 response that contains additional information pertinent to the application, such as "Incorrect password. Please try again."

---

In these steps, you'll configure HTTP Exception Mapping to replace the error message from the web application with a generic error response. You can use a stack trace response generated by the Oak sample application to test your error mapping configuration.

The Oak sample application can be induced to return a stack trace by going to the payment page directly, without following the order processing procedure. To view a raw stack trace in the browser, go directly to the following address:

http://<Oak_VirtualURL>/payment.do

Notice that the error response page includes a significant amount of information on the application.

Mapping HTTP Exceptions

To map HTTP exception responses to a generic error message, follow these steps:

---

Step 1 Click the Profiles link in the Manager navigation menu, and then click on the name of the profile you created, Poison Oak Traffic Validation.

Notice that the HTTP Exception Mapping active security feature is currently disabled in this profile.

Step 2 Click the edit link next to HTTP Exception Mapping.

The HTTP Exception Mapping settings page appears, as shown in Figure 14-1.

Figure 14-1 HTTP Exception Mapping

Step 3 In the Default Exception Mapping section, leave the For service errors ... not specified below menu set to the pass through value that is its default setting.

This setting indicates that the other controls on the page specify a subset of errors to replace with your own message. If you wanted to replace all errors from the backend service with a generic 500 message, you would choose the replace with generic 500 item from this menu.

Step 4 In the Mapped Exceptions section of the page, type 400, 403, 500-599 into the Status Codes field.

This value specifies that the ACE Web Application Firewall is to replace any of the HTTP 400, 403, and 500 through 599 errors with a custom message.

Step 5 In the Mapped Response Message section, choose the fixed value from the Status Code menu.

This setting indicates the status code for the response. Other than a numeric value, the code value is not restricted in any way, which provides flexibility in how the response is constructed. For example, you could return a 200 response (indicating a successful response) with the error message in the HTML body of the response.

In this case, we'll keep the default status code number, 500, and title, Server Error.

Step 6 In the Response Body field, type a message body such as "Big Error". In an actual implementation, you would type the text that you want to appear in the client's browser.

Step 7 Click Save Changes.

The HTTP Exception Mapping section of your profile now indicates that exception mapping is enabled and lists the mapped HTTP exceptions.

Step 8 Deploy the policy to have the changes take effect.

---

In the next section, you'll test your mapping configuration.

Testing HTTP Exception Mapping

Once you've configured HTTP Exception Mapping and deployed the new policy, you can see your new exception mapping rule at work.

When testing HTTP exception mapping, it is important to note that Microsoft Internet Explorer browser includes a feature that modifies HTTP errors presented in the browser. The feature, called "show friendly HTTP error messages," is automatically enabled in Internet Explorer. (Mozilla FireFox shows the original error message from the backend system.) To test the error mapping with Internet Explorer, you will first need to disable friendly HTTP error messages. Disable it by unchecking the option labelled Show friendly HTTP error messages in the Advanced tab of the Internet Options dialog in Internet Explorer.

To test error mapping:

---

Step 1 In your web browser, access the payment.do page of the Poison Oak sample application by requesting it directly in the browser:

http://<Oak_VirtualURL>/payment.do

Step 2 Ensure that instead of displaying a detailed stack trace, your browser displays the generic error message you configured.

---