The CompatResourceServlet has this code which the Verascan picks up a potentially dangerous:

...
    private static final String BASE_PATH = "com/icesoft/faces/resources";
...
        String path = httpServletRequest.getPathInfo();
        final InputStream in = loader.getResourceAsStream(BASE_PATH + path);
...

The challenge is to "sanitize" the path variable so that getResourceAsStream isn't allowed to return anything it isn't supposed to. The JavaDoc for getPathInfo():

"Returns any extra path information associated with the URL the client sent when it made this request. The extra path information follows the servlet path but precedes the query string and will start with a "/" character."

All I can think of being a problem here is someone crafting the request so that the path ends up containing some directory manipulation (e.g. "/../../../..") that might allow access to something outside of what the BASE_PATH sets. The method isn't going to execute anything like a script.

Consulted with Ted and this appears to be very low risk. We could just reject any strings containing ".." and log a security warning. I suspect that there is no security hole here, but rejecting ".." would be the safest thing to do.

So I've added a check to the path value that will check for paths with ".." in them and if it detects one:

• log a security warning
• return a 404

Not sure whether this will satisfy the Veracode scanning or not but should satisfy the spirit of the issue.

Hello Deryk,

This fix produce Null pointer exception on URL's like "http://host/url-pattern", "http://host/url-pattern/". On this url's getPathInfo() method return null,
and throw null pointer exception here "(path.contains("..")) {".

Thanks.

Thanks for catching this. Since 3.2 is no longer under active development, I've opened a new JIRA (ICE-9942) targeted for the next release and applied a patch.