URLScan Documentation Contradiction (I think)From: McCammon, Keith (Keith.McCammon@eadvancemed.com)
- Previous message: Mike Coppins: "Re: net use and LM / NTLM"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 12 Apr 2002 11:43:42 -0400 From: "McCammon, Keith" <Keith.McCammon@eadvancemed.com> To: <firstname.lastname@example.org>
So I'm fiddlin' with URLScan, and I get to reading the docs. Here's
what I find for AllowDotInPath:
"If set to 1, UrlScan rejects any requests containing multiple instances
of the dot (.) character. If set to 0, UrlScan does not perform this
The default is 0. Thus, I should be able to have (for example) a dot in
a directory name, and URLScan will let this pass, because it isn't
checking this directive. But then, I read this:
"Setting AllowDotInPath to 0 defends against the case where an attacker
uses path info to hide the true extension of the request (for example,
something like "/path/TrueURL.asp/BogusPart.htm"). Setting
AllowDotInPath to 0 also causes UrlScan to deny any request that
contains a dot in a directory name."
But the section above states that setting to 0 means that URLScan
doesn't perform the test!
On a somewhat unrelated and argumentative note, I would also think that
AllowDotInPath=1 would indicate that it should allow a dot within the
path (e.g., a dot in a directory name). Makes sense, right? Apparently
Does anyone know how this directive actually functions?
-- Keith W. McCammon