Hello and thanks to those of you out there using UrlScan.
There have been a couple of suggestions for allow list support in UrlScan. I am thinking about how best to incorporate this and wanted to get a feel for what would work for you.
My first thought is that I should not provide an allow list where the presence of a substring causes a request to bypass rules. The problem with this is that an attacker could then bypass any of your rules by just appending a string from your allow list to their attack. It needs to be a complete match. For example, an [AllowQueryString] entry of "safeqs" would cause only the exact query string "safeqs" bypass query string rules; "safeqsx" would not pass. Also, I would consider making the allow list case sensitive (The [AllowVerbs] section is case sensitive, but all deny lists in UrlScan are case insensitive.)
I'm also thinking about what allow lists are needed.
I am considering an [AllowUrl] list that bypasses VerifyNormalization, AllowHighBitCharacters, AllowDotInPath, MaxUrl, DenyExtensions and ScanUrl in rule sets. The URL would always be evaluated for this rule as if NormalizeUrlBeforeScan=1 is set.
I am also considering an [AllowQueryString] list that bypasses UnescapeQueryString, MaxQueryString, DenyQueryStringSequences and ScanQueryString in rule sets. Handling UnescapeQueryString for this rule is not as straightword as handling NormalizeUrlBeforeScan above. UrlScan knows that IIS will always normalize the URL, but it has no way of knowing whether the target page will do any decoding on the query string or not.
Would this functionality meet the need and improve UrlScan? Please feel free to comment and/or make alternative suggestions.
Disclaimer: I cannot promise that we will implement any particular functionality for the RTW release, but we will condsider all feedback.
Thanks,
-Wade