Re: urlscan 2.5 bug?
From: Karl Levinson [x y], mvp (levinson_k_at_despammed.com)
Date: 06/25/03
- Next message: Bob Smith: "Re: IIS Lockdown and dotNET"
- Previous message: Karl Levinson [x y], mvp: "Re: IIS port 80 to 443 redirect"
- In reply to: Wade A. Hilmo [MS]: "Re: urlscan 2.5 bug?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 25 Jun 2003 14:04:28 -0400
The original poster's mention of default documents makes me wonder if he is
having troulbe getting to the default document at the root of the server due
to the issue below:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312376
In which case, adding the . as the file extension is the correct thing to
do, instead of using AllowDotInPath, as mentioned in the documentation.
[If the OP's quibble is that this is not mentioned prominently enough in the
documentation, or that having to add a . as a valid file extension could be
a possible weakening in security, or that he had to manually make a change
that should arguably be included in the default URLScan settings, those may
or may not be valid complaints. Certainly I have had that same thought
myself with previous versions of URLScan. I couldn't tell from the article
whether this issue persists in URLScan 2.5, so I'm only guessing as to
whether this is the issue here.
"Wade A. Hilmo [MS]" <wadeh@microsoft.com> wrote in message
news:OpFWayyODHA.2460@TK2MSFTNGP10.phx.gbl...
> Hi s_m_b,
>
> Can you please clarify what you think is a bug in UrlScan?
>
> From your post below, I'm seeing two potential issues:
>
> First, I am guessing that you are trying to get UrlScan to use the
> [AllowExtensions] section and provide a list of inclusive list of allowed
> extensions. To this list, you want to add "none" as an allowed extension.
> In this case, you have done exactly the right thing by adding "." as an
> allowed extension. It would be very bad (and confusing) to get an empty
> line in the [AllowExtensions] section to mean "go ahead and allow URLs
with
> no extension", so we use the dot to represent this. You can do the same
> thing in the [DenyExtensions] section if you set UseAllowExtension=0 and
> want to deny requests that have no file extensions in the URL. Note that
> this capability didn't exist in UrlScan 1.0 and was added in 2.0 based on
> customer feedback.
>
> The second issue that I see is confusion about what AllowDotInPath really
> means. I understand the confusion, since the name of that option is a bit
> unfortunate. I've included an excerpt below from something I wrote a
while
> ago that describes the actual meaning of this option and why it's named
the
> way it is.
>
> I hope that this helps to clear up the issues you are seeing.
>
> Thank you,
> -Wade Hilmo,
> -Microsoft
>
> ----------
>
> Question:
>
> What is rationale behind UrlScan not allowing dot in Vdir path?
>
> Answer:
>
> Consider the following URL:
>
> http://server/foo.bar/boo.baz
>
> In order to determine the file extension of the URL (so that we can do the
> [AllowExtensions] and [DenyExtensions] stuff correctly), we need to know
> where the URL stops and the PATH_INFO begins. In my example above, there
> are two possible ways to interpret the string:
>
> - The URL could be "/foo.bar" and "/boo.baz" might be additional path
info
> (per the CGI spec.) In this case, the file extension is ".bar".
>
> - Or, the URL could be "/foo.bar/boo.baz", where boo.baz is a file in a
> directory called foo.bar. In this case, the file extension is ".baz".
>
> - Or, the URL could be "/foo.bar/boo.baz", where boo.baz is a
subdirectory
> of foo.bar, and it would either produce a directory listing or show a
> default document, in which case, the file extension is "".
>
> It turns out that, in order to answer this question definitively, you must
> read the metadata for the request. Since UrlScan runs before the server
has
> a chance to read metadata, it must make a "guess" as to what the file
> extension is. In some cases (ie. http://server/foo.bar), it can have high
> confidence that its guess is correct. In some cases, as above, it has low
> confidence about its guess.
>
> The AllowDotInPath setting is rather unfortunately named. In early (pre
> 1.0) versions of UrlScan, it literally counted dots in the path to
determine
> whether its guess was accurate or not. By the time it shipped, the logic
> was much smarter, but it was too late to change the name of the option.
The
> correct way to interpret AllowDotInPath is to say "If AllowDotInPath=1,
then
> process all requests as if we were perfect when we guessed the file
> extension. Otherwise, if AllowDotInPath=0 is set, then we will reject
> requests where we have low confidence in our guess of the file extension."
> If you are using file extension as a means to reject requests, I would
> strongly recommend that you set AllowDotInPath=0. Setting it to 1 leaves
> the opportunity for clever URL twiddling hackers to come up with a URL
that
> confuses UrlScan and ends up getting past your config settings.
>
> "s_m_b" <smb20002ns@hotmail.com> wrote in message
> news:Xns93A57A190EFE5smb2000nshotrmailcom@206.127.4.10...
> > can't find this in the ini file or the page on ms...
> >
> > AllowDotInPath=1
> >
> > doesn't work, certainly on IIS4. I've had to add the '.' as a valid file
> > extension.... whereupon it works?
> >
> > Major PITA for directory listing denied/default document set up !
>
>
- Next message: Bob Smith: "Re: IIS Lockdown and dotNET"
- Previous message: Karl Levinson [x y], mvp: "Re: IIS port 80 to 443 redirect"
- In reply to: Wade A. Hilmo [MS]: "Re: urlscan 2.5 bug?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
