Web Application Defender's Cookbook

Recipe 14-1: Using Redirection to Error Pages

This recipe shows you how to use ModSecurity’s redirect action to send clients to a user-friendly error page.

Ingredients

• ModSecurity
  • SecRuleUpdateActionById directive
  • redirect action

The main advice I give to new web application defenders who ask how they should actively respond to attacks is to mimic how the application itself responds to abnormal requests. Most web applications have their own built-in error-handling mechanisms and do not use the default web server error pages. A common error response method is for applications to use HTTP redirection to instruct the web browser where to go next. As an example, look at the following HTTP response:

HTTP/1.1 302 Found
Date: Tue, 04 Sep 2012 18:47:09 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Location: /error.aspx?reason=Invalid+Login
Set-Cookie: amUserId=; expires=Mon, 03-Sep-2012 18:47:09 GMT;
path=/
Set-Cookie: amCreditOffer=; expires=Mon, 03-Sep-2012 18:47:09 GMT;
path=/
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Content-Type: text/html; charset=utf-8
Content-Length: 132

In this case, the web application found a problem with the request and decided to respond with a 302 Found HTTP status code. The Location header instructs the web browser what web page to request: /error.aspx?reason=Invalid+Login. This web page gives the user more information about the reason for the error and usually includes instructions for contacting support ...