Re: AllowDotInPath
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 02/04/04
- Next message: MikeS: "Re: "Access is Denied" when giving cmd.exe parameters"
- Previous message: Adriane Hoffman: "updates??"
- In reply to: Greg: "Re: AllowDotInPath"
- Next in thread: Mark Challender: "RE: AllowDotInPath"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 4 Feb 2004 12:35:13 -0800
Greg, I think Wade has already answered your question. Let me try to
address what I think is one of your confusion points.
Specifically, Wade is pointing out that URLScan is NOT able to determine the
actual file extension for a given request 100% of the time, and
AllowDotInPath controls whether URLScan allows URLs with "ambiguous"
extensions to execute or not.
With AllowExtension of .htm and .cfm and AllowDotInPath=0, it means that
URLScan will only allow URLs that unambiguously resolve to .htm and .cfm to
pass. If URLScan wagers that it can guess wrong about the extension, it
will error on the side of safety and reject it.
For example, in the case of "/shoptest/showitems.cfm/CategoryID/16.htm"
with AllowDotInPath=0, URLScan actually looks at it and says "hmm, the
extension could be either .cfm or .htm , but since I can't be certain, I'm
not letting it pass". It is NOT implementing the logic of "hmm, the
extension could either by .cfm or .htm, and since both are in
[AllowExtension], I'm letting it pass". The reason it's not the latter is
because, as Wade pointed out, URLScan is not able to unambiguously resolve
the extension of a given request 100% of the time.
With AllowExtension of .htm and .cfm and AllowDotInPath=1, it means that
URLScan will allow URLs that appear to resolve to .htm or .cfm to execute
(if it passes all other checks). Thus, if URLScan guesses wrong about the
extension it will error on the side of "compatibility" and let it slide.
The security question involved here is:
IIS uses the extension to determine which piece of code executes on the
server. Thus, controlling which extensions are allowed to pass will
directly control what can be executed on the server. URLScan is a tool that
is taking guesses at the extension, and AllowDotInPath controls whether
URLScan lets the ambiguous extensions slide or not.
AllowDotInPath=0 is a more secure configuration because it rejects requests
if ambiguous at the possibility of giving false-positives. In your case,
you want to have some of the false-positives be allowed, but other false
positives can be security threats. You will have to look at locking your
server down further, outside of URLScan, to mitigate those threats.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Greg" <anonymous@discussions.microsoft.com> wrote in message
news:90d801c3ea4b$34c924b0$a001280a@phx.gbl...
>-----Original Message-----
>Hi All,
>
>You should be aware that setting AllowDotInPath=1 has
some security
>ramifications. Here's a bit of the back story on why
AllowDotInPath exists,
>and why it's rather poorly named:
>
>UrlScan has the capability of allowing or rejecting a
URL, based on the file
>extension represented in the URL. Unfortunately, it's
not always possible
>to know what that file extension is just from looking at
the URL alone.
>
>Consider, for example the URL from the log entry below
>("/shoptest/showitems.cfm/CategoryID/16.htm"). Is it a
request for a .cfm
>file with "/CategoryID/16.htm" as the path info (per the
CGI spec)?
Yes, this is how it is setup.
If so,
>then it would be a .cfm request. What if, on the other
hand, showitems.cfm
>is a physical directory with a subdirectory called
CategoryID that contains
>a file called 16.htm? In that case, it would be a
request for a .htm file.
>If you allow .htm, but not .cfm, or vice versa, this is
a very significant
>piece of knowledge.
I allow both .htm and .cfm in the AllowExtensions
section. BTW, my challenge has been fixed with
AllowDotInPath = 1. But now I'm concerened that I should
not have it set to 1. Are there some specific security
docs somewhere I can read that shows me the consequences
of setting this to 1?
Thank you for your reply, this cleared things up for me!
>
>Unfortunately, deciding how to interpret the URL
requires knowing something
>about the configuration of the web server itself.
Specifically, for IIS,
>you need to know whether ".cfm" is script mapped for
that particular URL or
>not. Since UrlScan runs very early in the request
processing, this
>information is not available at the time it needs it.
The server core
>itself doesn't even know yet at the time UrlScan runs.
>
>To work around this, a very early, prerelease version of
UrlScan did a
>simple count of the dots in the URL, hence the name
AllowDotInPath. If you
>wanted to restrict the URL to just one dot, to remove
any ambiguity about
>the file extension, then you set AllowDotInPath=0. As
it turns out, the
>release cycle for UrlScan was very short. When it
became clear in testing
>that the algorithm to figure out the file extension
needed to be quite a bit
>smarter than just counting dots, we made the changes
necessary to
>accommodate a wide range of real world URLs with
AllowDotInPath=0. By this
>time, it was too late to easily change the name to
something more
>descriptive of its actual purpose. If you think of it as
>"AllowAmbiguousFileExtensions", you'd get the right idea
of what it actually
>does.
>
>Finally, getting back to my original point that there
are security
>ramifications, if you set AllowDotInPath=1, you need to
be aware that the
>capability of UrlScan to reject requests based on file
extensions is
>hampered. You should not depend on on the fact that
UrlScan will be able to
>accurately determine the file extension.
>
>I hope that this information helps to fill in some of
the gaps.
>
>Thank you,
>-Wade A. Hilmo,
>-Microsoft
>
>PS: If someone finds a piece of UrlScan documentation
that incorrectly
>describes AllowDotInPath, in particular if it
mischaracterizes the 0 vs 1
>semantics, I will get the information to the correct doc
people.
>
>"David Wang [Msft]" <someone@online.microsoft.com> wrote
in message
>news:eZkyOyf6DHA.3860@tk2msftngp13.phx.gbl...
>> In your case, you want AllowDotInPath=1 to turn off
the check for dots in
>> the URL.
>>
>> --
>> //David
>> IIS
>> This posting is provided "AS IS" with no warranties,
and confers no
>rights.
>> //
>> <anonymous@discussions.microsoft.com> wrote in message
>> news:8de401c3e9f9$859f3d40$a001280a@phx.gbl...
>> Thank you for the reply! I have found the same
>> challenge, documentation seems to be contradicting. I
>> have tried both 0 and 1. I have restarted IIS and just
>> to be sure rebooted the machine with both instances. I
>> have URLScan 2.5, to the best of my knowledge this is
the
>> latest version. Here is a snippet from the log file:
>> URL contains '.' in the path. Request will be rejected.
>> Site Instance='11', Raw
>> URL='/shoptest/showitems.cfm/CategoryID/16.htm'
>>
>> I really don't want to remove URLScan from this
machine.
>> What are the consequences of doing this? If all
patches
>> are applied and the machine is behind a firewall.
>>
>> Thanks again,
>> Greg
>>
>> >-----Original Message-----
>> >I found a post from Keith McCammon and other places
>> stating that the URLScan
>> >documentation gives contradictory information about
>> whether you want
>> >AllowDotInPath to be = 1 or = 0. Have you tried both
1
>> and 0? You do of
>> >course have to save the URLSCAN.INI file and restart
the
>> IIS services for
>> >the settings to take effect, and you should
immediately
>> be able to confirm
>> >what settings are applied by looking in the
URLSCAN.LOG
>> file after the
>> >service starts up.
>> >
>> >http://archives.neohapsis.com/archives/sf/ms/2002-
>> q2/0151.html
>>
>http://www.tacteam.net/isaserverorg/spskit/4urlscan/4urls
>> can.htm ... claims
>> >that 1 is what you want
>> >http://www.iisfaq.com/default.aspx?View=A384&P=134 ...
>> claims that 0 is what
>> >you want
>> >
>> >Also, make sure you have downloaded the latest version
>> of URLSCAN. Early
>> >versions had problems with AllowDotInPath, as per
here:
>> >
>>
>http://www.microsoft.com/windows2000/downloads/recommende
>> d/urlscan/default.a
>> >sp
>> >
>> >Also, I assume you've looked in the URLSCAN.LOG file
to
>> confirm that the
>> >allowdotinpath statement is really the thing that is
>> blocking your requests?
>> >
>> >
>> >"Greg" <anonymous@discussions.microsoft.com> wrote in
>> message
>> >news:906f01c3e9f2$0d40bdd0$a401280a@phx.gbl...
>> >> Hello,
>> >>
>> >> I need to disable AllowDotInPath in URLScan but I
can't
>> >> seem to get this accomplished. Here is the
scenario,
>> >> trying to create search engine friendly URL's. So
my
>> URL
>> >> may look like this
>> >> http://domain.com/test.htm/category/id/15.htm.
URLScan
>> >> is rejecting this because of the dot in path. I
don't
>> >> want to disable URLScan all together, just this one
>> >> part. Any help would be appreciated.
>> >>
>> >> Windows 2000 Server
>> >> IIS 5.0
>> >> URLScan 2.5
>> >>
>> >> Thanks,
>> >> Greg
>> >
>> >
>> >.
>> >
>>
>>
>
>
>.
>
- Next message: MikeS: "Re: "Access is Denied" when giving cmd.exe parameters"
- Previous message: Adriane Hoffman: "updates??"
- In reply to: Greg: "Re: AllowDotInPath"
- Next in thread: Mark Challender: "RE: AllowDotInPath"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
