Spring Boot Security HttpFirewall

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.

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.

 

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 White List

Rejects HTTP methods which are not part of the allowable white 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 whitelist“.

You can override this behavior by specifying your own white list via method setAllowedHttpMethodsIt 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 ..

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&#1072;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 | Black List

We end off with the URL black 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 ..

 

 

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.