1

BACKGROUND

  • Application based on : Spring MVC
  • Java8
  • Mostly filter requests out by using interceptors.

PROBLEM

I tested my application and every user inputs are vulnerable to HTML/Script injection attacks. I'm using a certain methods to prevent them on my client side, but if I manipulated the form values before they're posted up to the server, the injections were successfully made and corrupted my website. So what's my top priority becomes having the same detection methods in server side as well. I should have done this eariler, but there's some reason anyway...

WHAT I'M THINKING OF

is to check every parameters in an interceptor. The interceptor will validate all the parameters wherever the page provides user inputs and forms to submit.

SOMETHING LIKE THIS

public class ParameterFilteringInterceptor {
     // 1. get all request parameters..
     // 2. check every values..
     // 3. if illegal characters exist in one of them, 
     //    converting or escaping them will start and change them to acceptable values.

     // Getting and setting on request parameters is going to occur frequently.

     // If good to go, return true
     // Or return false with a proper error message.
}

SETUP LIKE THIS

    <interceptor>
        <mapping path="/addform" />
        <mapping path="/editform" />
        <mapping path="/post" />
        <mapping path="/newarticle" />
        <mapping path="/newcomment" />
            .
            .
            .
            <!-- Depend on the volume of a web application,
            these mapping paths could be sooooooooo many. -->
        <beans:bean class="com.company.web.interceptor.AuthenticatingInterceptor"></beans:bean>         
    </interceptor>

So.. what I want to ask is.. "IS IT A GOOD IDEA TO DO SOMETHING LIKE ABOVE?"

hina10531
  • 3,938
  • 4
  • 40
  • 59
  • 1
    As a matter of practice, yes, you should validate every single parameter in a request because it cannot be assumed that the request comes from a human through a validated UI. You can use a proven framework like HDIV instead of using custom validations. – manish Jul 20 '15 at 08:26
  • 1
    Why don't you validate all the input in the model by JSR303 annotations. You would have to write less code. If you are using Spring form tags the input data directly goes to model where it gets validated then in the controller method if there are errors the form page is redisplayed if no errors then the input process completes. – underdog Jul 20 '15 at 08:40
  • 2
    To do it on every parameter, regardless of what the parameter **means** is probably wrong in general. It may work for simple cases but ideally you should sanitize your inputs in context of their semantics. If your input something that is displayed on a HTML page, you want to strip `<` characters. If your input is a mathematical formula, you probably don't. – biziclop Jul 20 '15 at 09:06

1 Answers1

3

Attempting to escape or otherwise reject cross-site scripting (XSS) attempts on submission isn't a good idea. There are a few issues with this approach:

  • The proper method to escape user input depends on where you want to inject it. Using content that has been improperly escaped may lead to display issues — the user sees garbage — or unexpected XSS vulnerabilities.
  • Because your user content will already be escaped for display, you have to avoid escaping it again. This means that you'll have to treat user input from the database and user input from other sources differently in your templates, or you'll get the same issues as in the point above.
  • Escaped content in your database needs special treatment when you don't want to use it for display as you will need to unescape it. This adds unnecessary boilerplate code, reduces interopability, and can lead to bugs.
  • It's hard to differentiate between legitimate XSS attacks and innocuous use of reserved characters like <, >, " or '. Approaches like tag stripping (i.e. removing everything that looks like HTML tags) can destroy user content.

Instead, you should appropriately escape your content as soon as it is displayed. Here's a pretty good writeup that elaborates further reasons why escaping on input is a bad idea.

Templating frameworks supported by Spring have shortcuts for escaping content.

Personally, I suggest using Thymeleaf: It escapes user input by default for HTML content and attributes — doing otherwise requires the use of a specific Thymeleaf attribute — and it has shortcuts for escaping input for use in JavaScript or JSON embedded on the page (see bottom).

If you're using another templating framework (or JSPs), consult its documentation to find out how to escape content on display. Note that some templating frameworks do not escape by default and/or don't offer different escaping methods. The former can lead to XSS vulnerabilities when you forget to escape input somewhere, the consequences of the latter have been described above.

Mel Kicchi
  • 188
  • 1
  • 12
  • 1
    +1. There are good uses for input filtering (removing characters you never want, like control characters) and validation (making sure input fits expected formats for business rules), but the input stage is not the place to be thinking about escaping/injection issues. – bobince Jul 20 '15 at 16:27