James,
On 1/17/25 8:04 AM, James Matlik wrote:
When I'm talking about path parameters, it is in the context of how Open
API/Swagger defined them:
https://swagger.io/docs/specification/v3_0/describing-parameters/
Okay, that helps clear things up. In the URL specification (inherited by
HTTP) defines them differently:
https://www.rfc-editor.org/rfc/rfc3986.html#section-3.3
The term "path parameter" you are using is actually a "path segment" in
URL/HTTP terms.
The problem you are running into is that encoded slashes are often used
to attack servers by performing path-traversals or avoiding security
constraints. Let's say you are on Windows and there is a security
constraint that says "only admin users can access files in
D:\docroot\(ON\QC)". You have mapped URL-/ to physical-D:\docroot.
(Admittedly this is very contrived).
The attacker says "well, %29 is a backslash, so lemmie just check to see
if I can slip one past the security system" and requests
http://localhost:8080/group/%28ON%5CQC%29%20LOCAL. If the server is
fooled, the attacker gets to request that resource in that directory.
My guess is that Tomcat's "URL cleaner" is seeing that \, attempting to
"sanitize" it, and converting it to a / because that's the local
filesystem path separator. This makes security constraints much more
difficult to bypass.
My naïve reading of your desire to have
encodeSolidusHandling=PASS_THROUGH behave the same for / and \ seems
reasonable if a misnomer. I say "naïve" because others on this team have
spent countless hours of their lives mulling these things over and
getting the logic "just right".
I say it's a misnomer because "solidus" means literally / and not \.
encodeReverseSolidusHandling? encodeAntiSolidusHandling?
The encodeSolidusHandling configuration setting is there so we can have
a very secure default-configuration that prevents attacks on naive
applications. In your case, you have an application that (presumably)
knows exactly what it is doing, and therefore you have the option to
pass-through those solidus...es. Solidii? Whatever.
I think that actually having a separate configuration setting for
antisolidii handling makes more sense than having that existing setting
perform double-duty, since each one of those you allow to pass-through
opens the door slightly wider to an attacker.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
