path matcher does not behave as expected

[gucki]

Using caddy 2.6.4 and the following matcher:

@test {
  path /api/v1/servers/localhost/zones/test.com.
}

However, requests showing "uri": "/api/v1/servers/localhost/zones/test.com." in the caddy logs are not matched. When the path matcher doesn't have the "." at the end, it matches:

@test {
  path /api/v1/servers/localhost/zones/test.com
}

[mholt]

Ah, this is because of #2917:

// See #2917; Windows ignores trailing dots and spaces
// when accessing files (sigh), potentially causing a
// security risk (cry) if PHP files end up being served
// as static files, exposing the source code, instead of
// being matched by *.php to be treated as PHP scripts.
reqPath = strings.TrimRight(reqPath, ". ")

This is a security feature, so a fix will need to be sensitive to that.

[gucki]

Hi @mholt, it seems the referenced issue is only for FastCGI (see https://github.com/caddyserver/caddy/pull/2917/files)? Or did the implementation change over time?

[mholt]

Serving php relies on path matchers.

I'll see if there's a better way to do this.

[mholt]

I wonder if I limit this trimming behavior to only happen on Windows servers, would that be sufficient for you?

[gucki]

@mholt Yes, I'm not using Windows. However, I still don't really get why code in the FastCGI module affects my requests, as I'm not using FastCGI, PHP, ...

[mholt]

I might try that then.

However, I still don't really get why code in the FastCGI module affects my requests, as I'm not using FastCGI, PHP, ...

The only "fastcgi module" in Caddy is the transport that turns an HTTP Request into a Response. However, for PHP apps, that alone is not very useful, since PHP apps often rely on special rewrites and static file serving. The php_fastcgi directive of the Caddyfile bundles these up for users as a one-liner.

I may try a patch that only trims the dot and space on Windows; but unfortunately there is no known absolute fix unless Windows changes its exploitable behavior.

I'm open to suggestions!

[mohammed90]

Correction for the referenced code, it isn't in the FastCGI module but in the MatchPath module; but the reasoning is duplicated:

https://github.com/caddyserver/caddy/blob/master/modules/caddyhttp/matchers.go#L393-398

[mholt]

@mohammed90 Yes, thank you. I was linking to the fastcgi module to demonstrate its limited scope of HTTP Request -> Response functionality. I realize now I hadn't linked to the code I quoted above, which is indeed in the path matcher. Thank you for linking to that and clearing that up :)