caddyhttp: Sanitize the path before evaluating path matchers

[francislavoie]

I found an issue where it's possible to bypass path matchers by crafting a request with a path that doubles up slashes, or uses URL-encoded characters to smuggle the request past the path matcher.

This becomes a security issue, because auth gates using basicauth can be bypassed 😬

The solution is to unescape (convert URL-encoded characters) then clean the path, before matching.

This could be a breaking change if exact behaviour of the matcher is required (without cleaning the path). In that case, then it's possible to use the expression matcher to do a direct string comparison or regexp on the {http.request.uri.path} placeholder (or simply {path} in the Caddyfile). For example:

# Simple prefix match
expression `{path}.startsWith("/foo")`

# Complex regexp match
expression `{path}.matches("^/foo.*$")`

Example of an exploitable situation:

example.com {
	root * /srv

	basicauth /secret-files* {
		bob <hash>
	}

	file_server
}

It's expected that the path matcher /secret-files* will always require bob to be authenticated before they're let through to the file_server. But a request like //secret-files/uh-oh.txt would punch through unmatched, reaching file_server. The file_server handler does clean the path though (collapsing the doubled-up slashes), so it would serve /srv/secret-files/uh-oh.txt back to the client.

[mholt]

Thanks for finding and fixing this. I'm hoping this won't break legitimate use cases, but I'm glad there's a workaround. Will release this today.