tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Speed <>
Subject Re: DO NOT REPLY [Bug 4361] - SsiServlet potentially leaks files
Date Wed, 24 Oct 2001 23:00:52 GMT

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 

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}"

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?

-Paul Speed

Bip Thelin wrote:
> > -----Original Message-----
> > From: Paul Speed []
> >
> > 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
View raw message