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:
@Test public 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 +"!"));
}
@Test public 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}")publicSomeEntitygetOne(@ContextRequestContextctx,@PathParam("id")Stringid){returndao.findExistingById(ctx,id);}
|
gets flagged with errors such as:
|
MethodgetOne()at line 51of SomeEntityResource.java gets user input
forthe id element.Thiselement’s value thenflows through the code
without being properly sanitized orvalidated andiseventually displayed
to the user inmethod getOne()at line 51of
SomeEntityResource.java.Thismay 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]
<mailto:[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.
