Re: 404 handler mkicks in before ISAPI filter
From: David Wang [Msft] (someone_at_online.microsoft.com)
Date: 03/18/04
- Next message: DaveS: "Re: High cpu Utilization - IISState Log"
- Previous message: David Wang [Msft]: "Re: IIS 6.0 pages not loading on first connect, then all is fine."
- In reply to: Yoram Ayalon: "Re: 404 handler mkicks in before ISAPI filter"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 18 Mar 2004 04:55:02 -0800
FYI: You do NOT have control of URLs that will be sent to your server.
Hackers do not use your server application to make requests to your
application.
URL translation, in general, is full of potential for cannonicalization
security flaws, especially transformations that assume only valid input.
Just be careful of that.
--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Yoram Ayalon" <anonymous@discussions.microsoft.com> wrote in message
news:99B239C0-A8C8-4563-9FC8-9A42183A91C6@microsoft.com...
Wade,
Thanks again for the help. Everything you say if of course correct. However,
I do have control over the URLs that will be sent my way, since they are all
generated by my server application. The following is true for my
application:
The application does NOT create a URL that contains a folder name with no
filename.extension. The only place where you have no filename.extension is
if it just contains the hostname with no folders. If a user would manually
change a URL so it ends with a folder name without the filename he will get
a 404 and this is OK with me.
The application does not generate a URL that contains a "." besides as a
separator between filename.extension
My server application does not generate a URL that contains a "/" inside a
query string.
So I am applying the following rules for my ISAPI filter, and so far, after
a week of testing they seem to hold:
Any empty URL or one that contains a "?" (question mark ) is ignored.
Any URL that contains "_vti" is ignored (for compatibility with Front Page
Server Extensions)
The filter works backwards until it finds a "." (dot) or until the start of
the url string, replacing "/" with "=" , "&" and "/" as needed. I make
sure I have an even number of "/"
Regards,
Yoram Ayalon
----- Wade A. Hilmo [MS] wrote: -----
Hi Yoram,
The value you are getting for the URL is coming straight from the
client.
It is normal that the client does not send the host name as a part of
the
URL. After all, the client only needs the host name to be able to
connect
to the server (unless the client is configured to use a proxy, in which
case
you would see the whole URL, including protocol and host name.) Your
filter
will need to be able to deal with this. Note that you can probably get
the
host name from the "Host:" header, although it's not guaranteed that
HTTP/1.0 clients will send you one (it's required that an HTTP/1.1
client
include a host header.)
I should point out here that it's not possible to "look" at a URL and
separate the path info from it. It sounds like you are making some
assumptions that won't be valid on a closer inspection. For example,
consider the following URL. I assume that this URL would represent the
case
you mean when you say "to finish with an explicit filename before any
optional parameters":
http://server/foo.bar/goo
The client will send you "/foo.bar/goo" as the header. What does that
mean?
Does it mean that "foo.bar" is a file, and "goo" is path info?
Does it mean that "foo.bar" is a directory and "goo" is a file in that
directory?
Does it mean that "foo.bar/goo" is a directory, and you want the
default
file in that directory?
Does it mean that "/foo.bar/goo" is path info to be given to the
default
file in the root directory?
You can't tell without knowing a whole lot about both how the server is
configured (ie. how to map to a physical directory, whether there is a
script mapping, etc.), and how the physical directory structure is laid
out.
Unfortunately, in PREPROC_HEADERS, none of this information is
available to
you. This information would be available in SF_NOTIFY_AUTH_COMPLETE,
but I
suspect that the file existence verification happens before
AUTH_COMPLETE.
I realize that this doesn't necessarily help you with the final
resolution,
but I want to be sure that you know the full challenge of what you are
trying to do. I do not believe it's possible to write a generic
solution.
If you know your clients well enough, though, you may be able to make
some
assumptions about what they are trying to do.
Thank you,
-Wade A. Hilmo,
-Microsoft
"Yoram Ayalon" <anonymous@discussions.microsoft.com> wrote in message
news:972F9D5A-7153-467C-8F1F-3597F57BC7F8@microsoft.com...
> Wade,
>> You are right! I installed debugging code in my filter and verified
I only
get the part of the URL after the host name.
> So, unless there is a way to get the host name part, and in my case
its
not constant but could be one of many pointing to the same server, I
can
make this work ONLY if I make sure all URLs to my server either contain
only
hostname (plus optional params in format /param1/value1/....) OR, if
they
contain folders, to finish with an explicit filename before any
optional
parameters.
>> in any case this is my call to SetHeader :
>> pHeaderInfo->GetHeader(pCtxt->m_pFC,"url", url, (unsigned long
*)&len);
> //allocate the right amount of memory
> url = (char *) pCtxt->AllocMem(len+2);
>> // now get the url string
> if ( pHeaderInfo->GetHeader(pCtxt->m_pFC,"url", url, (unsigned long
*)&len) )
> ...
> ... code snipped...
> ...
> if (replace) {
> pHeaderInfo->SetHeader(pCtxt->m_pFC, "url", url);
> }
>> thanks,
> yoram ayalon
>
- Next message: DaveS: "Re: High cpu Utilization - IISState Log"
- Previous message: David Wang [Msft]: "Re: IIS 6.0 pages not loading on first connect, then all is fine."
- In reply to: Yoram Ayalon: "Re: 404 handler mkicks in before ISAPI filter"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
