Hi,

Dropwizard doesn't filter input parameters in JAX-RS resource classes by 
default, but you could relatively easy create such a filter yourself (see 
http://jkoder.com/anti-cross-site-scripting-xss-filter-for-java-web-applications/
 
<http://jkoder.com/anti-cross-site-scripting-xss-filter-for-java-web-applications/>
 for a very simple example).

And maybe someone has already done so for JAX-RS in general.

We're looking forward to your findings!

Cheers,
Jochen

> Am 23.01.2017 um 17:53 schrieb Jacek Furmankiewicz <[email protected]>:
> 
> Hi,
> 
> We're running a scan of our code in a commercial security static code 
> analysis tool and it is flagging pretty much nearly every usage of JAX-RS 
> input
> parameters as a High Severity security issue.
> 
> For example, a typical JAX-RS method like this:
> 
> @GET
> @Path("/{id}")
> public SomeEntity getOne(@Context RequestContext ctx, @PathParam("id") String 
> id) {
>  return dao.findExistingById(ctx, id);
> }
> 
> 
> gets flagged with errors such as:
> 
> Method getOne() at line 51 of SomeEntityResource.java gets user input for the 
> id element. 
> This element’s value then flows through the code without being properly 
> sanitized or validated and is eventually displayed to the user in method 
> getOne() at line 51 of SomeEntityResource.java. This may enable a 
> Cross-Site-Scripting 
> 
> 
> 
> So I my question is whether Dropwizard automatically sanitizes PathParam 
> FormParam, CookieParam, etc against XSS attacks?
> 
> Or do we need to do it in every JAX-RS method manually and sanitize every 
> argument ourselves? 
> 
> Thanks
> Jacek

-- 
You received this message because you are subscribed to the Google Groups 
"dropwizard-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to