URL Rewrite identity rules re-decode `Request.Path`

[DeagleGross]

A rewrite rule that matches Request.Path and re-emits the same captured segment (even a no-op/identity rule) can change the path value, because the rule matches against Request.Path.ToString() (escaped form) and reassigns via PathString.FromUriComponent() (decodes again). A path already containing a literal %2e (from Kestrel's normal single decode) becomes .. after passing through the rule.

Repro

app.UseRewriter(new RewriteOptions()
    .AddRewrite("^test/(.*)", "test/$1", skipRemainingRules: true));
app.Run(ctx => ctx.Response.WriteAsync(ctx.Request.Path));

Request: GET /test/%252e%252e/secret

• Before rewrite: Request.Path = /test/%2e%2e/secret
• After rewrite: Request.Path = /test/../secret

Expected: pass-through rewrite rule should not change Request.Path's value.

[uzair4991]

Hey, I'd be happy to pick this one up if nobody's on it yet.

I dug into it a bit and I think the problem is that RewriteRule matches on Request.Path.ToString(). That goes through ToUriComponent(), which doesn't touch anything that already looks like %XX, so a literal %2e comes out as %2e. Then FromUriComponent() decodes it again and we end up with ..

My idea is to escape the % before matching, something like:

var value = path.Value;
if (value.Contains('%'))
{
    value = value.Replace("%", "%25");
}
var input = new PathString(value).ToUriComponent();

That way we encode once and decode once, and a pass-through rule leaves the path alone. Paths without a literal % wouldn't change at all, and stuff like %20 in replacement strings would keep working the same way.

It looks like the IIS and mod_rewrite rules (and RedirectRule) do the same thing, so I'd probably make a small shared helper and use it in all of them.

For tests I was thinking %252e%252e, %252F, %253F, a % followed by non-hex chars, and a few normal/non-ASCII paths to make sure nothing else breaks.

Does that sound reasonable? Happy to change direction if you had something else in mind.