denyUrlSequences documentation is correct but not practical

[starlight54]

https://docs.microsoft.com/en-us/iis/configuration/system.webserver/security/requestfiltering/denyurlsequences/

The documentation here lists .. as an example of blocking requests using denyUrlSequences, with reference specifically to preventing directory traversal. However, it does appear that this method doesn't actually block these sequences with otherwise default configurations, although in principle the article is correct.

The reason being that something (not third party, but Windows default behaviour, maybe HTTP.sys?) intercepts and performs some Url resolution ahead of the Request Filtering module. In this case it specifically resolves any directory traversal sequences in the path and removes them from whichever parameter the IIS Request Filtering module is using (maybe {URL}?), thus it never sees the .. and so the request is not blocked despite the rule.

This can be easily seen by using the HTTP.sys log, if I request as follows:

GET https://host/app/whatever/%2f..%2fcontent%2floader.gif HTTP/1.1

Then I see in the log:

<EventData>
    <Data Name="RequestObj">0xFFFFE18EBB3C5050</Data>
    <Data Name="HttpVerb">       4</Data>
    <Data Name="Url">https://host:443/app/content/loader.gif</Data>
</EventData>

And the IIS Request Filtering module does not block the request and logs the path as /app/content/loader.gif in it's own logs under the default W3SVC directory. This does represent a security concern, since this means that denying the Url sequence .. will not prevent directory traversal as described by default (in the context of a complete Windows Server). Note it is possible to block this sequence using a Url Rewrite rule with the {UNENCODED_URL} parameter.

Is this an IIS bug?

If not, should we add a note to the docs explaining that modifications may be made to the Url prior to these rules being applied? Also note that it converts \ to / in the same fashion.