Thanks for the heads up on @SafeHtml,that looks like a lifesaver. We enhanced our app to scan all the DAOs in our Spring context and find all the entity types that get persisted to DB. Then we scan each of these types via Reflection to find all the String fields and ensure that every one of them is marked with @SafeHtml.
If any of them are not, the app throws a SecurityException right at start up and refuses to run. So this should ensure developers will add it everywhere. That should prevent any XSS data getting persisted to DB (e.g. in a free-form name or description field on an entity). Will look next at potentially sanitizing the incoming input as well via a Jersey filter. Thanks Jacek On Mon, Jan 23, 2017 at 10:35 PM, Eric Lambart <[email protected]> wrote: > Hi Jacek, > > If you had numeric ids you'd get implicit validation. That is, if you have > a Long id, and someone tried to give you xss content as the value of your > parameter, the request simply wouldn't match your resource method, and the > attacker would get a 404. > > But with String ids you're in a bit of trouble. With @Path("/{id}") and > @PathParam("id") > String id, you are saying you'll accept *any *String. So you've allowed > XSS code to get inside your resource method... and you'd really rather it > had stayed away.. > > But maybe it's not too much trouble! Unless your ids are some sort of > truly random text (without any strict character limitations and/or > formats), you can specify a regex for the {id} in the path. For instance, > if you use UUIDs, you could do something like this: > > @GET@Path("greeting/{id: [-a-z0-9]+}")@Produces(MediaType.TEXT_PLAIN)public > String giveGreeting(@PathParam("id") String id) { return "hello " + id + "!"; > } > > I tested that and it works. Here are the corresponding JUnit tests that > show that one is accepted and the other gets a 404: > > @Testpublic void allow_UUID() { > String id = "4df57308-39cd-4003-a0ec-38c70c3afdad"; > String hello = client() > .resource("/api/ammin/greeting/" + id) > .accept(MediaType.TEXT_PLAIN).get(String.class); > assertThat("we're friendly", hello, is("hello " + id + "!")); > } > @Testpublic void ignore_XSS() { > thrown.expect(UniformInterfaceException.class); > thrown.expectMessage("Client response status: 404"); > client() > > .resource("/api/ammin/greeting/%3Cscript%3Ewindow.alert(%22l33t%20h%40x0r%22)%3C%2Fscript%3E") > .accept(MediaType.TEXT_PLAIN).get(String.class); > } > > If you also accept String-containing DTOs via POST etc., you can use the > javax.validation API to validate your DTOs. Malicious requests with data > that don't pass validation will get... an HTTP 406 (bad request), I think. > They won't get inside *your* code in any case. > > @POST@Timed@UnitOfWork@Path("greeting/{id: [-a-z0-9]+}")public void > acceptGreeting(@PathParam("id") String id, @Valid GreetingDTO userGreeting) { > // ... > } > > You can then use Hibernate validation's @SafeHtml on any String fields in > your DTOs, and any attempts to send bad HTML should be stopped at your > door. I hope that helps. I'm curious what your static analysis tool thinks > of those ideas. Eric > On 01/23/2017 08:53 AM, Jacek Furmankiewicz wrote: > > 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 dropwizard-user+unsubscribe@ > googlegroups.com. For more options, visit https://groups.google.com/d/ > optout. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "dropwizard-user" group. > To unsubscribe from this topic, visit https://groups.google.com/d/ > topic/dropwizard-user/JpFNjuvDvek/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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.
