Using an attributePrefix of "HTTP_" should be guarded
Basics
Logistics
Basics
Logistics
Description
There seems to be an accidental behavior on IIS by which using an attributePrefix setting of HTTP_ causes the server variable setter in the IIS filter to actually create headers that seem to be showing up under all the usual APIs in ASP/NET that access headers.
This is probably vulnerable to smuggling/spoofing due to the logic for preventing that being off when useHeaders is false. That should be tested but is probably the case.
Warning is the bare minimum on this, but I think it probably needs to be blocked outright, and it serves no purpose if this is actually the case since just turning headers on would be equivalent.
Environment
None
Activity
Scott Cantor
December 1, 2020 at 6:39 PM
Added a warning and signaled this will be blocked in a future release.
Scott Cantor
April 24, 2020 at 12:20 AM
As expected, a missing attribute that's mapped can be spoofed by sending a header if this trick is used.
It doesn't trivially appear possible to spoof a populated attribute due to the API being used, it's probably doing a Set instead of Add, but that's rarely foolproof and doesn't really change anything. It resembles some of the earliest IIS problems before the logic was fixed.
There seems to be an accidental behavior on IIS by which using an attributePrefix setting of HTTP_ causes the server variable setter in the IIS filter to actually create headers that seem to be showing up under all the usual APIs in ASP/NET that access headers.
This is probably vulnerable to smuggling/spoofing due to the logic for preventing that being off when useHeaders is false. That should be tested but is probably the case.
Warning is the bare minimum on this, but I think it probably needs to be blocked outright, and it serves no purpose if this is actually the case since just turning headers on would be equivalent.