[
https://issues.apache.org/jira/browse/WW-5645?focusedWorklogId=1030008&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1030008
]
ASF GitHub Bot logged work on WW-5645:
--------------------------------------
Author: ASF GitHub Bot
Created on: 13/Jul/26 06:55
Start Date: 13/Jul/26 06:55
Worklog Time Spent: 10m
Work Description: lukaszlenart commented on PR #1777:
URL: https://github.com/apache/struts/pull/1777#issuecomment-4955252139
Hi @arunmanni-ai — thanks for checking first. I'd hold off on the `%2e`
reject: it isn't needed, and `canonicalisePath()` is the wrong place for it.
I ran the two failing tests plus the loader-level one to be sure of the
behaviour:
- `resolveResourcePath("jquery/%2e%2e/%2e%2e/etc/passwd")` returns
`META-INF/resources/webjars/jquery/3.7.1/%2e%2e/%2e%2e/etc/passwd` — non-empty.
The WebJar locator resolves the **version** and passes the `%2e%2e` segments
through without checking the file exists. `canonicalisePath()` correctly leaves
them alone, because `%2e%2e` is not a literal `..`.
- End-to-end it's already a 404: `DefaultStaticContentLoaderWebJarTest`
(incl. `webJarEncodedTraversalReturns404`) passes. The bogus resolved path is
handed to `getResource`, which does **not** URL-decode, so `%2e%2e` is a
literal segment that matches nothing → 404.
So there's no traversal to defend against — the old `URLDecoder.decode` was
the only thing that turned `%2e%2e` into `..`, and that's gone. The two failing
tests assert a stricter-than-reality contract (resolver must return empty for
encoded-dot paths) for a case that can't traverse.
Why not add `%2e` to `canonicalisePath()`:
1. It's a pure path normaliser — mixing in content-filtering muddies its
contract and reintroduces the denylist we moved away from.
2. `%2e` is only dangerous if something decodes it, and nothing does
anymore, so rejecting it implies a risk that no longer exists.
3. It only patches `%2e`; the real looseness (the locator resolves *any*
non-existent filePath to a bogus path, e.g. `jquery/does-not-exist.js`) stays.
Suggested resolution, in order of preference:
1. Drop or rewrite the two failing tests to assert the real property — that
these paths aren't *servable* (404 end-to-end). That's already covered by
`webJarEncodedTraversalReturns404`, so they're largely redundant.
2. If you want resolution-layer strictness for hygiene, have
`resolveResourcePath` verify the resolved resource actually **exists** (a
positive check) rather than denylisting `%2e` — that rejects `%2e%2e` and every
other non-existent path generically. Keep `canonicalisePath()` pure.
Either is fine by me; I'd just avoid putting a denylist back into the
normaliser.
Issue Time Tracking
-------------------
Worklog Id: (was: 1030008)
Time Spent: 1h 20m (was: 1h 10m)
> Canonicalise static content paths and remove redundant URL decode
> -----------------------------------------------------------------
>
> Key: WW-5645
> URL: https://issues.apache.org/jira/browse/WW-5645
> Project: Struts 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 7.2.1
> Reporter: Arun Manni
> Priority: Minor
> Fix For: 7.3.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> buildPath() in DefaultStaticContentLoader applies URLDecoder.decode() to
> resource paths that the servlet container has already decoded. This redundant
> decode serves no purpose and conflicts with the servlet spec's path handling
> contract.
> This patch removes the unnecessary decode and the now-unused encoding
> field/setter, adds a Validator.canonicalisePath() utility that normalises the
> path (resolves . and .., converts \ to /) and returns Optional.empty() when
> the resolved path escapes above root, wires the canonical path through both
> findStaticResource() and the WebJar split() so downstream lookups use the
> normalised form, documents the encoding contract on
> RequestUtils.getServletPath(), and adds test coverage.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
