As this example code builds upon the OverridableHttpRequest class discussed in the previous post, you will need that class (or your own comparable implementation) before you get started. Once you have that, the code for the filter implementation is not very complex:

public class InputSanitizerFilter implements Filter {
	private static final Logger LOG = Logger.getLogger(InputSanitizerFilter.class);
	
	private static final String BANNED_INPUT_CHARS = ".*[^a-zA-Z0-9\\@\\'\\,\\.\\/\\(\\)\\+\\=\\-\\_\\[\\]\\{\\}\\^\\!\\*\\&\\%\\$\\:\\;\\? \\t]+.*";
	
	public static final String QUARANTINE_ATTRIBUTE_NAME = "filter.quarantined.params";
	public static final String SUSPICIOUS_REQUEST_FLAG_NAME = "filter.suspicious.request";

	@Override
	public void destroy() {
		//no work necessary
	}

	@Override
	@SuppressWarnings("unchecked")
	public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
		//wrap the original request and set up an empty quarantine map
		OverridableHttpRequest newRequest = new OverridableHttpRequest((HttpServletRequest)request);
		Map<String, String> quarantine = new HashMap<String, String>();
		newRequest.setAttribute(QUARANTINE_ATTRIBUTE_NAME, quarantine);
		
		//inspect each parameter, and move any suspicious ones into thw quarantine area
		Enumeration<String> names = request.getParameterNames();
		while (names.hasMoreElements()) {
			String name = names.nextElement();
			String value = request.getParameter(name);
			if (value.matches(BANNED_INPUT_CHARS)) {
				//uh-oh, found something that doesn't look right, quarantine it and make sure the request is flagged as suspicious
				LOG.warn("Removing potentially malicious parameter from request:  " + name);
				quarantine.put(name, value);
				newRequest.removeParameter(name);
				newRequest.setAttribute(SUSPICIOUS_REQUEST_FLAG_NAME, "true");
			}
		}
		
		//done, send the modified request on down the chain
		chain.doFilter(newRequest, response);
	}

	@Override
	public void init(FilterConfig arg0) throws ServletException {
		//no work necessary
	}
}

Basically there is a regex that defines the set of disallowed characters (anything that is not a letter, number, standard punctuation character, or whitespace…this example will also exclude any parameters that contain newlines as the webapp that it is used in does not contain any inputs that can accept newlines, but you can obviously modify it to your liking), and every parameter in the request is inspected to see if it contains one or more banned character(s). Any parameter that is found to include banned characters is copied into the ‘quarantine‘ map, and then removed as a parameter (so calling ‘request.getParameter(“badParam”)‘ will return null). This will prevent application code from ever seeing the suspect parameter(s), unless it explicitly goes looking inside of the quarantine map (which you might do if you want to allow users to have special characters in their password, for instance).

Also, if one or more parameters are quarantined, the request is flagged as suspicious by setting an attribute named ‘filter.suspicious.request‘. This gives code downstream from the filter a quick way to see if the request has been modified by the filter in any way, and allows the application to make its own decisions about whether or not it wants to venture into the quarantine area to inspect the potentially unsafe data. For instance:

if (request.getAttribute(InputSanitizerFilter.SUSPICIOUS_REQUEST_FLAG_NAME) != null) {
    Map<String, String> quarantine = (Map<String, String>)request.getAttribute(InputSanitizerFilter.QUARANTINE_ATTRIBUTE_NAME);
    for (String key : quarantine.keySet()) {
        System.out.println("Quarantined parameter:  name=" + key + ", value=" + quarantine.get(key));
    }
}

…or, with the right frameworks in place you might easily create something like an ‘@IgnoresQuarantine‘ annotation that can be applied selectively to business methods to mark a parameter (or set of parameters) as not subject to quarantine on calls to that method so that you never need to manually go looking through the quarantine area (after implementing the annotation and its backing logic). But that’s just slightly outside of the scope for today.

Sadly, apart from being difficult to navigate, some of the information on the official ‘UrlRewriteFilter‘ website pertaining to setup and usage of the filter is also incorrect/out of date. This is really quite a shame, because ‘UrlRewriteFilter‘ is an excellent little utility and I’m quite tired of seeing people needlessly running multi-server configurations (typically Apache httpd for static content, and something like Tomcat, Resin, Jetty, etc. for dynamic content) out of a desire to use this-or-that particular module that only works with httpd or (even worse) out of the outdated and no-longer-relevant notion that servlet containers cannot efficiently serve static content. So in an effort to save ‘UrlRewriteFilter‘ from obscurity and an undeserved death at the hands of poor documentation and a shoddy distribution site, here is a complete set of instructions for getting the filter to work in your webapp.

First, you will need to ensure that the ‘UrlRewriteFilter‘ JAR file is on your web-application’s classpath. How you do this will depend upon your build process/how you are constructing your webapp(s), but long story short placing the JAR file in your webapp under ‘/WEB-INF/lib’ will do the trick, and if you’ve spent any time at all working with webapps you probably already have a preferred way of doing this. Alternately, you may want to install the JAR file in your servlet container’s ‘/lib’ folder, particularly if you are deploying multiple webapps on your server and you want to have ‘UrlRewriteFilter‘ available to any/all of them automatically.

In any case, once you have the ‘UrlRewriteFilter‘ JAR on your webapp’s classpath, the real setup can begin. Open your application’s ‘web.xml‘ file, and add the following filter configuration to your webapp:

<!-- URL rewriting -->
<filter>
    	<filter-name>UrlRewriteFilter</filter-name>
      	<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
      	<init-param>
        	<param-name>logLevel</param-name>
        	<param-value>WARN</param-value>
        </init-param>
</filter>
<filter-mapping>
    	<filter-name>UrlRewriteFilter</filter-name>
    	<url-pattern>/*</url-pattern>
</filter-mapping>

This instructs the servlet container to route every request that the server receives through the ‘UrlRewriteFilter‘. Note that although it is not discussed on the official site, that ‘logLevel‘ parameter is absolutely essential. If you omit it, the filter will fail to initialize properly and yield some very bizarre behavior.

Anyways, once your ‘web.xml‘ has been updated, the final step is to add a ‘urlrewrite.xml‘ file in the same directory as your ‘web.xml‘ file, and configure it to your liking. Here is an example ‘urlrewrite.xml‘ file with a couple basic rewrite rules:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 3.2//EN"
        "http://tuckey.org/res/dtds/urlrewrite3.2.dtd">
<urlrewrite>
    <!-- user-account activation link -->
    <rule>
    	<from>/activate/([a-f0-9]+)?(.*)</from>
     	<to>/userController?action=activateUser&amp;token=$1&amp;$2</to>
    </rule>

    <!-- default rules included with urlrewrite -->
    <rule>
        <note>
            The rule means that requests to /test/status/ will be redirected to /rewrite-status
            the url will be rewritten.
        </note>
        <from>/test/status/</from>
        <to type="redirect">%{context-path}/rewrite-status</to>
    </rule>
    <outbound-rule>
        <note>
            The outbound-rule specifies that when response.encodeURL is called (if you are using JSTL c:url)
            the url /rewrite-status will be rewritten to /test/status/.

            The above rule and this outbound-rule means that end users should never see the
            url /rewrite-status only /test/status/ both in thier location bar and in hyperlinks
            in your pages.
        </note>
        <from>/rewrite-status</from>
        <to>/test/status/</to>
    </outbound-rule> 
</urlrewrite>

This defines two rules. The first simply rewrites URL’s of the form ‘/activate/######?[params]‘ to something like ‘/userController?action=activateUser&token=######&[params]‘, and the second is the default example rule that comes with ‘UrlRewriteFilter‘ and allows you to see a basic diagnostic page by pointing your browser at ‘[your server]/test/status‘.

And there you have it. Quite simple, really, and now there’s one less reason to continue running two distinct server instances where one would do just as well.