IIS: % in URL is double-unescaped

[mus65]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

We have a method with the template "api/{id}" where id is a string. So when we want to pass the literal "%abc", the encoded url is api/%25abc .

By default, IIS will reject this with status 404.11 due to security reasons. We have to set the following in web.config for IIS to allow this:

<system.webServer>
    <security>
      <requestFiltering allowDoubleEscaping="true" />
    </security>
</system.webServer>

The issue is that while this works with the example string "%abc", other values break or even cause internal exceptions due to ASP .NET Core unescaping the already unescaped URL. For example calling "api/%2542" which should result in id being the literal "%42" instead results in "B".

The URL api/%2500" even causes the following exception because 00 is unescaped to a null-byte.

Microsoft.AspNetCore.Server.IIS.Core.IISHttpServer: Error: Connection ID "17654110548687585306", Request ID "4000001b-0002-f500-b63f-84710c7967bb": An unhandled exception was thrown by the application.

System.InvalidOperationException: The path contains null characters.
   at Microsoft.AspNetCore.Internal.UrlDecoder.DecodeCore(Int32& sourceIndex, Int32& destinationIndex, Span`1 buffer)
   at Microsoft.AspNetCore.Internal.UrlDecoder.DecodeInPlace(Span`1 buffer)
   at Microsoft.AspNetCore.Http.PathString.FromUriComponent(String uriComponent)
   at Microsoft.AspNetCore.Builder.Extensions.UsePathBaseMiddleware.InvokeCore(HttpContext context, String matchedPath, String remainingPath)
   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContextOfT`1.ProcessRequestAsync()

This is with Windows 11 and the latest .NET Hosting Bundle 6.0.4. I can't reproduce this with IIS Express. #30655 may be related, but it does not seem to be specific to IIS.

Expected Behavior

Value from URL is unescaped correctly.

Steps To Reproduce

Define the following method:

[HttpGet("test/{id}")]
public ActionResult Get(string id)
{
  return Ok(id);
}

Start the application in IIS (not IIS Express).

Calling the URL "test/%2500" will cause the mentioned internal exception. Calling "test/%2542" will return "B".

Exceptions (if any)

Microsoft.AspNetCore.Server.IIS.Core.IISHttpServer: Error: Connection ID "17654110548687585306", Request ID "4000001b-0002-f500-b63f-84710c7967bb": An unhandled exception was thrown by the application.

System.InvalidOperationException: The path contains null characters.
   at Microsoft.AspNetCore.Internal.UrlDecoder.DecodeCore(Int32& sourceIndex, Int32& destinationIndex, Span`1 buffer)
   at Microsoft.AspNetCore.Internal.UrlDecoder.DecodeInPlace(Span`1 buffer)
   at Microsoft.AspNetCore.Http.PathString.FromUriComponent(String uriComponent)
   at Microsoft.AspNetCore.Builder.Extensions.UsePathBaseMiddleware.InvokeCore(HttpContext context, String matchedPath, String remainingPath)
   at Microsoft.AspNetCore.Server.IIS.Core.IISHttpContextOfT`1.ProcessRequestAsync()

.NET Version

6.0.4

Anything else?

No response

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[JamesNK]

@Tratcher Could you look into this? It lines up with the other work we're doing to improve URL escaping.

[Tratcher]

This looks like a regression in 6.0 caused by the following change: 56d0f2a

remainingPath was a PathString, but now it's using the implicit converters to become a string, and the converters encode/decode. Flowing the value as a PathString should fix this.

Recommended for servicing.

[Tratcher]

The same PR introduced the same regression in MapPath.
56d0f2a#diff-65457624537493466dc6a9609fb01fcb49e5f17e687b04827aa4231daf44c5d6R67

[Tratcher]

Re-opening to consider for servicing.

@mus65 can you test the builds from main in a few days to see if this resolves your issue? https://github.com/dotnet/installer#table

Is this an issue that's blocking you from using 6.0?

[mus65]

@Tratcher I tested it successfully with the main build. Thanks for the quick fix!

We hit this in production with 6.0 and it's too late to go back to 3.1, so a patch would be great. So this would be in 6.0.5 which is released in may, right?