Requests for static resources trigger a security error during mime type detection #254
Comments
|
@kothar any chance you have some sample code I can test with? |
|
Sure - I have put together a working example: https://github.com/kothar/spring-lambda-test If you run the spring app directly, you can successfully request both /static.html and /dynamic Running the tests against the patch in #255 succeeds. |
|
Thanks. I can make this work in my environment by explicitly enabling the path during the cold start: LambdaContainerHandler.getContainerConfig()
.addValidFilePath("/Users/xxx/workspace/aws-serverless-java-container/aws-serverless-java-container-spring");It's a bit more work but I feel it's the safest way to enable access to static files. Would this not work for you @kothar? |
|
@sapessi I can confirm that the workaround above works for me. You might want to use in the unit test. While I'm perfectly happy to use this approach for my application, it seems to me that the fundamental problem is not the valid paths, but the implementation of In practice, the file name passed in to the method is not the path of an actual file, but the path of an HTTP request. For static files this is unlikely to be the correct path of the file on disk, and for dynamic requests the file may not even exist, and the type detected may be used to route to the correct handler. This method is essentially saying: "given a hypothetical file xyz.html, what would the mime type be based on the file extension?". Requiring that we mark all paths in the application working directory as valid seems unnecessary and potentially a risk if the same security check is used in other places. My preference would be to keep the security check in place, but to isolate the file system That's just my view of the problem, I am happy to leave it as-is if you disagree :) |
|
You make a fair point @kothar and I'd be happy to change the implementation to work how you propose. Looks like that's exactly how Tomcat implements it. Before I go ahead with the change, I'd like to get confirmation that this is the only way the method is used. I cannot find anything explicit in the Servlet specifications. I'll keep googling for now. |
…the mime type from the file name, without probing the file system. Updated unit tests to match (#254)
|
Release 1.3.2 - which includes this fix - is on its way to maven central! Resolving this issue. |
|
Thanks for taking the time research a proper patch @sapessi! That seems a much better solution. |
Scenario
Hosting static resources (e.g. css or js files) from a /static folder on the classpath.
Expected behavior
The static file is served by the service
Actual behavior
Requests for paths with extensions causes
getMimeTypeto be called on theAwsServletContextclass. This in turn callsSecurityUtils.getValidFilePath(String).The string input to
getMimeTypeis treated as a relative path, which fails the security check.My understanding is that Spring is passing in the request path rather than it's true location (possibly embedded inside a jar file, or non-existent in the case of API endpoints). Prefixing non-absolute paths with
"/tmp/"allows the content type to be correctly probed, although the file does not exist at that path.Issue #158 resolves a similar problem with the rest container mappings by disabling extension-based mime type detection and avoiding this call completely, but static resources are requested by a different route and not affected by the fix in that issue. Additionally, it is desirable for the mime type detection to work as expected for static files, rather than disabling it.
Steps to reproduce
Request a static resource with a file extension (or a rest path which appears to have a file extension, as per #158)
Full log output
The text was updated successfully, but these errors were encountered: