[2.1] Remove cookie name decoding

[Tratcher]

Description

Decoding arbitrary input for cookie names allows spoofing of special inputs like __Host- with encoded values like __%48ost-.

Fix: Only compare to known values. e.g. the key the developer passes in with the encoding we would have used.

This fix works seamlessly for the indexer and TryGetValue, but leaves the encoded value in enumerator.

Customer Impact

Security

Regression?

No, reserved name prefixes are a newer browser cookie feature.

Risk (see taxonomy)

Low. It's not clear than many customers were dependent on the encoding/decoding behavior for cookie names. There is a mitigation in place that works for most scenarios, and a compat switch to opt out of the change.

Link the PR to the original issue and/or the PR to master.

#23578
#23579
#24389
aspnet/AspNetKatana#368.

Packaging impact? (if a libraries change)

• Microsoft.AspNetCore.Http

[ghost]

Hello human! Please make sure you've included the Shiproom Template in a comment or (preferably) the PR description. Also, make sure this PR is not marked as a draft and is ready-to-merge.

[Tratcher]

@dougbu can this be merged, or do you want to wait for #24375?

[dougbu]

Only thing blocking a merge is shiproom (Tactics) approval.

[Tratcher]

It was already approved at the same time as #24389. I think @leecow forgot the new label?

[jeran-urban]

Hello,

Can anyone verify that GHSA-hxrm-9w7p-39cc was permanently fixed for Mictosoft.AspNetCore.Http as of 2.1.22, and the higher versions, including versions 2.2.x no longer have this vulnerability? Sonatype is reporting this is still an active issue directly via support chat:

"""
For Microsoft.AspNetCore.Http:

So for the 2.1.x branch, we do have the vulnerable range closed off at 2.1.22 (not inclusive).

For the 2.2.x version, the advisory does not address this branch and we have found that it does have the vulnerable code in its versions. There are currently 5 2.2.x versions published to Nuget, the latest published on 2/12/2019, and all contain the vulnerable code. We are monitoring new releases of this component and will close off the vulnerable range for the 2.2.x branch should a fix ever be released for it.
"""

If you can verify, can you please provide documentation so I can try to get this updated? Thank you!

[ghost]

Hi @jeran-urban. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[dougbu]

@jeran-urban,

For the 2.2.x version, …

2.2.x was last patched on November 19, 2019 and reached end of life on December 23, 2019. Both dates were long before this PR was merged. Even 2.1.x is no longer supported except if using a subset of the packages on .NET Framework.

Please see https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core#lifecycle for more information.

[jeran-urban]

@jeran-urban,

For the 2.2.x version, …

2.2.x was last patched on November 19, 2019 and reached end of life on December 23, 2019. Both dates were long before this PR was merged. Even 2.1.x is no longer supported except if using a subset of the packages on .NET Framework.

Please see https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core#lifecycle for more information.

Sorry, to clarify, I am asking in regards to the Microsoft.AspNetCore.Http Nuget Package, version 2.2.x (in this specific case, 2.2.2), not the .net core parent framework. It is my understanding the Microsoft.AspNetCore.Http Nuget package is still in use and working against .net Core 5 and 6

[ghost]

Hi @jeran-urban. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.

[dougbu]

All Microsoft.AspNetCore.* v2.2.x packages ended support at the same time as the larger framework. From 3.1.0 on, Microsoft.AspNetCore.Http.dll is in the shared framework; no separate package needed.

[jeran-urban]

All Microsoft.AspNetCore.* v2.2.x packages ended support at the same time as the larger framework. From 3.1.0 on, Microsoft.AspNetCore.Http.dll is in the shared framework; no separate package needed.

thank you so much for the explanation. And sorry to seek further clarification:
2. for .net core >= 3.1.0 there are some external nuget packages that still depend on older versions of those same nuget packages that have been included into the shared runtime framework. Is there a way to prevent VS from pulling in those nuget packages as external resources, and instead have it reference the ones built in to the framework? Or is that just dependent on the specified nuget package and its transitive dependencies?

Thank you again!

[ghost]

Hi @jeran-urban. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context.