1

Recently, we found that some of our SpringMVC based site's pages, that accept query parameters, are susceptible to XSS attacks. For e.g. a url like http://www.our-site.com/page?s='-(console.log(document.cookie))-'&a=1&fx=326tTDE could result in the injected JS to be executed in the context of the rendered page. These pages are all GET-based, no POST requests are supported.

These parameters are written in the markup in numerous places, so doing an HTML encode (in all these places) would be tedious and require more code changes. In some cases, they are also written to cookies.

Ideally, we would want to detect them as early as possible, say inside a Servlet Filter/Spring Interceptor and then for each request parameter, decide if we want to drop it all together, or sanitize it in some way, before it's available to the rest of the application. We would want this decision to be configurable as well, so that the approach to handle a particular request parameter can be modified over time without significant code change.

Now, since these are request parameters that we want to potentially modify, we would probably have to use an approach similar to the one described here, if we go the Filter way. We would potentially want to sanitize HTTP Request Headers similarly too.

So, what would be the most flexible/minimum overhead way to handle this situation? Would ESAPI be able to both detect and sanitize them, in a configurable way? It's not clear from its API as to what is possible. We would definitely not want to hand-roll regexes to do this. Also, would a Filter be the right place to handle this?

Thanks.

Community
  • 1
  • 1
kodeninja
  • 339
  • 1
  • 7
  • 23
  • If your application uses external `js` files only, you could implement a [Content Security Policy](http://www.html5rocks.com/en/tutorials/security/content-security-policy/) that would prevent inline scripts from running if injected. – SilverlightFox May 05 '14 at 10:49
  • Unfortunately, no. We have a lot of inline JS (it's just how the system grew). We do have a separate effort to tidy things up, but fixing this security hole is the immediate priority. So, for now, we'd have to deal with the way the markup is currently being written, where we have inline JS in multiple places. – kodeninja May 05 '14 at 17:35

0 Answers0