how to exploit pathtraversal vulnerability

Question

I am pentesting an http server using jetty, where I have access to the code. One of the urls I am looking at is get /services/test.js

Looking at the code below:

    @GET
    @Path("services/{script:.+[.]js}")
    @Produces(MediaType.TEXT_PLAIN)
public Response servicesScript(@PathParam("script") String script) {
        try {
            if(script.lastIndexOf("/") != -1)
                return Response.status(Response.Status.NOT_FOUND).build();

    final InputStream scriptInputStream = getClass().getClassLoader().getResourceAsStream("script/" + script);

    if(scriptInputStream != null) {
        return Response.ok(CharStreams.toString(new InputStreamReader(
                scriptInputStream, Charsets.UTF_8))).build();
    } else {
        return Response.status(Response.Status.NOT_FOUND).build();
    }
} catch (IOException e) {
    throw new MxConsoleException("Invalid js requested: " + script, e);
}
}

It seems that it is checking if the script name includes "/" , I tried to url-encode this "/" and see if I can read /etc/passwd, but I couldn't. Same if I do double encoding. These are the crafted urls I tried:

GET /1/services/..%252f..%252f..%252f..%252f..etc%252fpasswd HTTP/1.1

GET /1/services/..%2f..%2f..%2f..%2f..etc%2fpasswd HTTP/1.1

Any idea if I can bypass this?

Answer 1

@Path("services/{script:.+[.]js}")

It seems this method only triggers for URLs that match this regular expression. That is, they have to end in .js.

I tried to url-encode this "/"

This typically works in a situation where the parameter is checked, url-decoded, then used. In your case the same method checks and uses the variable, and there is no url-decoding in between.

The docs for getResource say:

The name of a resource is a '/'-separated path name that identifies the resource.

So you would need a slash for the path, and that is not allowed in your method. With path traversals it is sometimes worth trying whether backslash as path separator works, but it is unlikely to work in this case.

So this is not exploitable.