Re: AllowDotInPath

From: Wade A. Hilmo [MS] (wadeh_at_microsoft.com)
Date: 02/03/04

  • Next message: Andre: "Help!! IIS and other snap-ins not working" 
    Date: Mon, 2 Feb 2004 19:40:02 -0800

    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)? 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.

    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: Andre: "Help!! IIS and other snap-ins not working"

    Relevant Pages

    • Re: AllowDotInPath
      ... AllowDotInPath exists, ... >to know what that file extension is just from looking at ... >then it would be a .cfm request. ... Since UrlScan runs very early in the request ...
      (microsoft.public.inetserver.iis.security)
    • URLScan Documentation Contradiction (I think)
      ... So I'm fiddlin' with URLScan, and I get to reading the docs. ... of the dot character. ... "Setting AllowDotInPath to 0 defends against the case where an attacker ... uses path info to hide the true extension of the request (for example, ...
      (Focus-Microsoft)
    • Re: URLScan Rejects header "transfer-encoding:"
      ... URLScan may block this type of request. ... "I really did not want to reconfigure the URLScan just to accomodate a JDK ... cause vulnerabilities on your server. ... configuration as you see fit and we provide the information to do this. ...
      (microsoft.public.inetserver.iis.security)
    • Re: urlscan 2.5 bug?
      ... as the file extension is the correct thing to ... do, instead of using AllowDotInPath, as mentioned in the documentation. ... myself with previous versions of URLScan. ... > want to deny requests that have no file extensions in the URL. ...
      (microsoft.public.inetserver.iis.security)
    • Re: urlscan 2.5 bug?
      ... Can you please clarify what you think is a bug in UrlScan? ... want to deny requests that have no file extensions in the URL. ... The second issue that I see is confusion about what AllowDotInPath really ... the file extension is ".bar". ...
      (microsoft.public.inetserver.iis.security)