tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Speed <psp...@progeeks.com>
Subject Re: DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files
Date Thu, 25 Oct 2001 18:26:14 GMT
Ok, I'm going to try again with the attachments.  Seems like only
the SSIInclude03.txt file came through before.

-Paul Speed

Paul Speed wrote:
> 
> I couldn't find alot of info on testing.  I also couldn't find any
> tests that included multiple files... so I may be looking in the wrong
> place.  I eventually found and played with the tester stuff.
> 
> Attached are the files I added to the tester to exploit the include
> problem.  SSIInclude09.shtml simply includes another .shtml file
> twice.
> 
> Here is the section I added to tester.xml to get the test to run.
>     <tester host="${host}" port="${port}" protocol="${protocol}"
>          request="${context.path}/SSIInclude09.shtml" debug="${debug}"
>           golden="${golden.path}/SSIInclude03.txt"/>
> 
> I now have this working on my system here.  It currently passes all
> of the tester tests in addition to about 7 more tests that I added
> myself here locally.  I also added the initial support for the "set"
> directive and variable substitution.  I have one more command to get
> working and then some clean-up and I'll see about posting the diffs.
> 
> Actually, while I'm on that subject, the diffs are extensive since
> I've pretty much touched every SSI related file in a very significant
> way... in addition to removing a few of them.  What is the preferred
> way to submit such a large patch?
> 
> Thanks,
> -Paul Speed
> 
> Bip Thelin wrote:
> >
> > > -----Original Message-----
> > > From: Paul Speed [mailto:pspeed@progeeks.com]
> > >
> > > For the curious reader, after looking into this code at some length
> > > it seems clear why the set command was not added.  All SSI requests
> > > share the same environment, which not only makes a set command
> > > impossible but also means that multiple SSI requests (or even nested
> > > SSI requests) trample all over each other.  A simple shtml file that
> > > includes two other shtml files illustrates this quite nicely.
> >
> > Do you have a smal testcase? We have unittests with Tomcat that have
> > nested includes and several includes in one page. All Ssi directives
> > share the same enviroment per page through a mediator, this is due to
> > the fact that you can have a config directive that changes the error
> > message that you would get for a failed include further down on the same
> > page, for instance.
> >
> > However if pageA includes pageB, if pageB is also an shtml/ssi file it
> > would have a new fresh enviroment and could not tamper with pageA's
> > enviroment.
> >
> > So you could easily do a set command simmilar to the config command.
> >
> > > Since I'm between assignments at the moment, I'm working on a patch
> > > here locally.  It's pretty significant, though, so it may take me a
> > > few days.  It will include the set command though since that's what
> > > I'm going to use to test it. :)
> >
> > Patches and additions are gladly appreciated.
> >
> >         Bip Thelin
> 
>   ------------------------------------------------------------------------
> This is Content of "includeme.shtml"
> 
> This is Content of "includeme.shtml"
Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message