0

I'm having a Spring Web Application that exposes REST APIs.
I have implemented XSS filter using Jsoup that strips the input using Safelist.NONE.

The penetration testing team raised a concern where the input field content is URL encoded, the XSS filter does not strip the data and allow the input to pass to the controller.

The input for the was: %3Cscript%3Ealert%285%29%3C%2Fscript%3E which is <script>alert(5)</script>

The usage of the input is: we are calling with this input to a 3rd party API that returns the field as it is, and we are returning it to the client (encoded as it came).

Is it an issue?
If so, what is the practice of catching such cases where we can't know if the input is URL encoded?

1 Answer 1

0

It is not safe to do any assumptions about how clients use the data received from the service. That's why we should expect that sooner or later they can be embedded in some web page to present them to user in some form.

That's why the service should sanitize any text data received from the client. The only exception is the case when the application is an HTML editor, then sanitizing logic is a bit more complex.

One of the approaches for sanitizing is following.

  • Unescape the text. Compare the result to the original text. If it differs, repeat it again, until the result does not differ from the previous step. This will mean that there is no escaping.
  • Then filter the text. There are different libraries for that. For instance, you can use AntiSamy.
  • Escape the filtered text back, if it is required by business logic.

In Java you can use URLDecoder, which is available out of the box. If you need to unescape more than URLs, look at HtmlUtils of Spring or StringEscapeUtils of Apache Commons.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.