httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@covalent.net>
Subject Re: [franklin_tech_bulletins@yahoo.com: IBM AS/400 HTTP Server '/' attack]
Date Fri, 09 Nov 2001 15:54:56 GMT
From: "Rodent of Unusual Size" <Ken.Coar@Golux.Com>
Sent: Friday, November 09, 2001 5:10 AM


> john sachs wrote:
> > 
> > anyway, in doing so, i noticed that 1.3 serves the page
> > as you'd expect.  in 2.0, you get 404.  which is "correct"?
> 
> 404 is most definitely not correct.  Adding a '/', optionally
> followed by more data, to the end of a mapped filename is
> perfectly valid and defines the 'path-info'.  1.3 seems to be
> correctly differentiating between the resource and its path-info;
> 2.0 is probably trying to treat the whole thing as a resource
> and hence not finding it.

Yes, and no.

Since the default handler doesn't glom onto trailing path_info,
it doesn't get handled.  All 1.3 pages I tested _without_ SSI's
enabled returned 404.

Since SSI is another beast, it accepts path_info and serves the
page.

It seems IBM's core handler was tweaked, and in doing so, exposed
this hole.

> Code for a 200 return, and a response body that matches the
> document's correctly-rendered (as opposed to raw) content.

That would be a good convention, against an SSI page.

The real issue is ending up with hundreds of robot hits (or goofy
caching state) against a site with an infinite number of pages...

/index.html
/index.html/hello?
/index.html/are/you/there

etc.  A possible convention, against the core handler, would be an
external redirect back to /index.html to keep all that cruft away.

CGI authors have to deal with this issue in whatever way is appropriate,
if they use path_info at all.

Bill



Mime
View raw message