[
https://issues.apache.org/jira/browse/CAMEL-24438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18109086#comment-18109086
]
Andrea Cosentino commented on CAMEL-24438:
------------------------------------------
Thanks [~davsclaus] - taking both points, and the PR is rescoped accordingly.
*Dropped:* the {{staticFileExtensions}} allow-list the first version added. It
restricted static content to web assets, which would have blocked exactly the
class-path loading you say is by design. Gone entirely; the class-path fallback
is untouched.
*Checked rather than assumed:* the traversal half does not arise. Vert.x has
already normalised the path by the time the handler runs - probed against
vertx-core 4.5.24, {{/../../etc/passwd}} collapses to {{/etc/passwd}}, which
then resolves relative to the working directory, and {{%2f}} is not decoded.
Nothing escapes upward, so there was no traversal to fix.
*Kept, because it matches "a path goes outside the project folder":*
{{staticSourceDir}} was a fallback rather than a source.
{code:java}
File f = new File(u); // process working
directory, first
if (!f.exists() && staticSourceDir != null) {
f = new File(staticSourceDir, u); // only if the CWD did
not have it
}
{code}
An operator who explicitly configures {{staticSourceDir}} gets it consulted
only for files the working directory does not already happen to hold. The PR
makes the configured directory authoritative when it is set, and refuses a path
that would still resolve outside it after canonicalisation. With no
{{staticSourceDir}} set the behaviour is unchanged - working directory, then
class path, as documented.
*Wider point, which is the more useful outcome here.* "Per design for
prototyping and development" is not currently written down anywhere a scanner
or a triager will look, which is why this came in as a finding at all. The PR
therefore adds a class to the security model's out-of-scope list:
{quote}
*Features whose documented purpose is prototyping and development.* Some
conveniences exist to make a local run or a demo easy, and their contract is
breadth rather than confinement. {{camel.server.staticEnabled}} serves static
content by resolving the request against the process working directory and then
the class path, so that an html/js file dropped next to the route, or packaged
in the jar, is simply served: loading resources from the class path is the
point of the option, not an oversight. Running such a feature on an untrusted
network is a deployment decision, and the surface it exposes there is operator
responsibility. A report is in scope only if the feature behaves outside its
own stated contract - for example serving a path outside a directory the
operator explicitly configured. Where a component or option is documented as
development-oriented, treat that documentation as the contract when triaging.
{quote}
If there are other options in the same category worth naming there, I am happy
to add them - the value is in the list being explicit.
PR: https://github.com/apache/camel/pull/25847
_Claude Code on behalf of oscerd_
> camel-platform-http-main - static file serving resolves against the process
> working directory and the classpath root
> --------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24438
> URL: https://issues.apache.org/jira/browse/CAMEL-24438
> Project: Camel
> Issue Type: Bug
> Components: camel-platform-http
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.23.0
>
>
> {{MainHttpServer.setupStatic()}} mounts a catch-all route at
> {{staticContextPath}} + {{"*"}} (default {{"/"}}) and resolves the requested
> path like this:
> {code:java}
> String u = ctx.normalizedPath();
> ...
> File f = new File(u);
> if (!f.exists() && staticSourceDir != null) {
> f = new File(staticSourceDir, u);
> }
> if (f.exists()) {
> is = new FileInputStream(f);
> } else {
> is = camelContext.getClassResolver().loadResourceAsStream(u);
> if (is == null) {
> is =
> camelContext.getClassResolver().loadResourceAsStream("META-INF/resources/" +
> u);
> }
> ...
> }
> {code}
> {{new File(u)}} resolves relative to the process working directory, and it is
> tried *first*. {{staticSourceDir}} is only consulted when that misses, so it
> behaves as a fallback location rather than as a root the lookup is confined
> to. The classpath root is then tried as well. There is no extension allowlist
> and no denylist.
> camel-main and camel-jbang deployments conventionally keep
> {{application.properties}} in the working directory, and the route is
> registered at {{order(Integer.MAX_VALUE)}} so it answers anything no consumer
> matched. Vert.x path normalization does prevent {{../}} escapes, but the
> working directory and the classpath are already the roots being served.
> Proposal: make {{staticSourceDir}} an actual root - resolve every request
> under it and reject anything that escapes - and confine the classpath lookup
> to a dedicated prefix such as {{META-INF/resources/}} instead of the
> classpath root. Needs an upgrade-guide entry, since deployments relying on
> working-directory resolution would have to set {{staticSourceDir}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
