Reading Time: 4 minutes

Did you know Spring Boot Security gives us a fully functional HTTP Firewall out of the box? Don’t worry if you didn’t because not many people do! In this post I’ll explain what Spring’s HttpFirewall is, what type of security protection it offers and where it’s positioned in Spring’s Security.

Spring Boot Security HttpFirewall

Spring Boot configures many aspects of security out of the box . One of those is a HTTP firewall which is implemented as interface type HttpFirewall. Much attention is usually placed on Spring’s security filters when discussing Spring Security (and rightfully so) but what isn’t obvious is that the HttpFirewall is our first line of defense.

This post covers Spring Boot 2 and Spring Security 5. The following Spring Boot starter dependency is all that is needed to get off and running and have the HttpFirewall auto configured.

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-security</artifactId>
</dependency>

<groupId>org.springframework.boot</groupId>

<artifactId>spring-boot-starter-security</artifactId>

</dependency>

If your interested in reading about Spring Boot’s default Security configuration then check out my post here.

HttpFirewall | First Line of Defense

Spring achieves this by including the HttpFirewall into its FilterChainProxy which then executes before any HTTP requests are sent through the filter chain. By default, a StrictHttpFirewall implementation is instantiated by FilterChainProxy which will reject and suspicious requests (more on this soon) with a RequestRejectedException.

public class FilterChainProxy extends GenericFilterBean {
	// ~ Static fields/initializers
	// =====================================================================================

	private static final Log logger = LogFactory.getLog(FilterChainProxy.class);

	// ~ Instance fields
	// ================================================================================================
        .... omitted for brevity

	private HttpFirewall firewall = new StrictHttpFirewall();

        .... omitted for brevity

public class FilterChainProxy extends GenericFilterBean {

// ~ Static fields/initializers

// =====================================================================================

private static final Log logger = LogFactory.getLog(FilterChainProxy.class);

// ~ Instance fields

// ================================================================================================

.... omitted for brevity

private HttpFirewall firewall = new StrictHttpFirewall();

.... omitted for brevity

There is another implementation called DefaultHttpFirewall which is ironically not the default and is much more forgiving than its stricter counterpart. It tries to rectify the issue by attempting to sanitize the URL instead of outright rejecting it however, Spring recommends using the StrictHttpFirewall instead – safer.

There are no loggers, nor logging messages in any of the HttpFirewall implementations. This possibly has contributed to the reason why this Spring Security feature has gone under the radar as we never see any mention of it in logs, especially on startup.

How Does HttpFirewall Protect Us?

Basically, the Http firewall implements rules that enforce added security to sanitize and protect us against potentially harmfully crafted URLs even before they reach the security filter chain.

Some, but not all of these protections can be customized/overridden via setter methods. I’ll cover the StrictHttpFirewall implementation specifically here as it make more security sense to do so.

HttpFirewall | HTTP Method Safe List

Rejects HTTP methods which are not part of the allowable safe list. This is specified to block HTTP Verb tampering and XST attacks. The default list allows for HTTP methods DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT.

If your try sending a TRACE or CONNECT, then that would be considered a forbidden HTTP method and therefore a RequestRejectedException would get thrown with message “The request was rejected because the HTTP method <HTTP Method> was not included within the safelist“.

You can override this behavior by specifying your own safe list via method setAllowedHttpMethods. It is also possible to turn this off and allow any HTTP method by calling setUnsafeAllowAnyHttpMethod(boolean) however this will open you up to HTTP verb tampering and XST attacks.

HttpFirewall | URL Normalization

URL/URI normalization is the process used to determine if the syntactically different URIs are the same. For example ..

http://example.com/foo → http://example.com/foo/
http://example.com/default.asp → http://example.com/
http://example.com:80/ → http://example.com/
http://example.com/foo//bar.html → http://example.com/foo/bar.html

http://example.com/foo → http://example.com/foo/

http://example.com/default.asp → http://example.com/

http://example.com:80/ → http://example.com/

http://example.com/foo//bar.html → http://example.com/foo/bar.html

Now if we take a look at this from a security point of view, this means that some hackers can craft certain URLs in a manner which bypasses security constraints.

You cannot disable this feature as it is considered extremely risky. If you want to relax the security, you can always fallback to the DefaultHttpFirewall or implement your own HttpFirewall with a mix of both strict and somewhat relaxed security constraints.

If a http request cannot be normalized, a RequestRejectedException would get thrown with message “The request was rejected because the URL was not normalized”.

HttpFirewall | ASCII Characters

This one is tricky as everything seems normal on the surface but actually your site www.yourbank.com might actually be another www.yourbank.com since the “a” in URL is actually a Unicode character like http://www.yourbаnk,com/ that looks like the English ASCII character “a” but is not!

HttpFirewall will ensure that the URL contains printable ASCII characters in range 0x20 to 0x7e and if it isn’t, it will throw a RequestRejectedException with message “The requestURI was rejected because it can only contain printable ASCII characters”.

There is also no way to disable this as it is considered extremely risky to disable this constraint.

HttpFirewall | Blocked List

We end off with the URL block list which rejects http requests which contain the following …

semicolons. You can override this with setAllowSemicolon(boolean)
URL encoded forward slash. (represented as %2f) You can override this with setAllowUrlEncodedSlash(boolean)
Backslash. You can override this with setAllowBackSlash(boolean)
URL encoded percent sign (represented as %25). You can override this with setAllowUrlEncodedPercent(boolean)
URL encoded period (represented as %2e). You can override this with setAllowUrlEncodedPeriod(boolean)

All of them have their unique security exploits (which I won’t get into) however if they are encountered you will get a RequestRejectedException with message “The request was rejected because the URL contained a potentially malicious String <forbidden_string>”.

Customize Spring Boot Security | HttpFirewall

The following can be used to customize the behavior of Spring’s HttpFirewall in Java Config ..

    @Bean
    public HttpFirewall looseHttpFirewall() {
        StrictHttpFirewall firewall = new StrictHttpFirewall();
        firewall.setAllowedHttpMethods(Arrays.asList("GET", "POST"));
        firewall.setAllowSemicolon(true);
        firewall.setAllowUrlEncodedSlash(true);
        firewall.setAllowBackSlash(true);
        firewall.setAllowUrlEncodedPercent(true);
        firewall.setAllowUrlEncodedPeriod(true);
        return firewall;
    }

@Bean

public HttpFirewall looseHttpFirewall() {

StrictHttpFirewall firewall = new StrictHttpFirewall();

firewall.setAllowedHttpMethods(Arrays.asList("GET", "POST"));

firewall.setAllowSemicolon(true);

firewall.setAllowUrlEncodedSlash(true);

firewall.setAllowBackSlash(true);

firewall.setAllowUrlEncodedPercent(true);

firewall.setAllowUrlEncodedPeriod(true);

return firewall;

}

HttpFirewall | Summary

Hopefully you now have a better appreciation with what you get out of the box with Spring Security. HttpFirewall might not get a lot of media attention but knowing how it protects us can go a long way in helping us understand and customize our application security.

Share this post:

Twitter Facebook Reddit Email