tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: Volunteers for: - RE: TC 3.3: getRequestURI()
Date Sun, 30 Sep 2001 02:01:33 GMT
It seems that I must have been bad in a past life, since my Karma isn't high
enough.:)

I've added the code to re-encode the URL to DecodeInterceptor on my machine.
If you want it right away, I can post a diff.
----- Original Message -----
From: <cmanolache@yahoo.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Friday, September 28, 2001 11:17 AM
Subject: Volunteers for: - RE: TC 3.3: getRequestURI()


>
> It seems most agree on using 'decoded' URI in mod_jk. Making the change
> is not easy, there are few places where we need to coordinate and make
> sure we're on the same page.
>
> I don't think I can do this alone ( if it sounded like I volunteer to fix
> it - well, I need  help ).
>
> Problems:
> - Someone with IIS must cut&paste the decoding stuff from Apache (
> probably in jk/common ), make sure the uri sent is decoded ( so consistent
> with Apache and NES ). That should happen in j-t and j-t-c ( with this
> ocasion we'll help Marc a bit :-)
>
> - One piece is to implement the java side of the decoding. I can do that
> if nobody else wants ( I have few other bugs in work, so I'll probably do
> it tommorow ).
>
> - I'll fix DecodeInterceptor to avoid double decoding ( I'm already fixing
> the normalization for JNI ).
>
> - Someone should check 4.0. Strange, even if this is a 2.3 requirement I
> didn't see any comment so far... Well, they have cool features and jars to
> add, so I can do that if nobody else does.
>
> - Revert jk/apache to use uri, remove the encode call ( again, j-t and
> j-t-c - one more week to do that, after that we'll be j-t-c only ). Henri
> - could you do this and the next one ?
>
> - Build and make some jars available - so we can test.
>
> - Test.
>
> Yes, it's a long list - but at the end we might solve one of the trickiest
> problems.
>
> Costin
>
>
>
> > >2. mod_jk will send the 'decoded' URI ( %xx replaced with the real
> > >char ).
> > >
> > >On IIS - we need to decode the URI, Apache+NES - nothing to do.
> > >On java side - we do a 'canonical' encoding in the facade. All
> > >the code will operate on the decoded request ( this is what
> > >Apache and NES are doing ). We also need to prevent DecodeInterceptor
> > >to re-decode the URIs from jk. ( that's trivial, just a flag )
> > >
> > >Benefits:
> > >- consistency with Apache, all processing on decoded uris.
> > >- easier to maintain ( java :-)
> > >- important - servlets will get a consistently encoded uri,
> > >thus preventing many security problems. With the current code
> > >many tricks can be played ( see recent security problems in
> > >tomcat ) using encoding - if we were vulnerable to that,
> > >I suspect most servlet authors will be as well.
> > >
> > >Problems:
> > >- a bit more work to do.
> > >- the 'original' uri will not be preserved in any servers (
> > >the first solution allows that for IIS and standalone ).
> > >
> > >
> > >Your votes please, I'm ok with any of them ( with a slight
> > >preference to 2 )
> > >
> > >Costin
> > >
> > >
> > >On Thu, 27 Sep 2001, Larry Isaacs wrote:
> > >
> > >>
> > >>
> > >> > -----Original Message-----
> > >> > From: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> > >> > Sent: Thursday, September 27, 2001 3:10 AM
> > >> > To: tomcat-dev@jakarta.apache.org
> > >> > Subject: RE: TC 3.3: getRequestURI()
> > >> >
> > >> >
> > >> > Given this is an important change - and something will be broken
> > >> > regardless of what we do - I think we need to coordinate
> > >and make sure
> > >> > we're doing it right.
> > >> >
> > >> > - First: Larry - what do you think ? We just had RC1, and we
> > >> > have already
> > >> > a simple patch ( changing SessionId to hide the problem ).
> > >My proposal
> > >> > is simple to implement ( just encode the URI on the facade, and use
> > >> > only decoded URIs internally ), but it is braking some of the 2.3
> > >> > clarifications ( not mandatory for 2.2, of course, but important )
> > >>
> > >> I'm leaning towards your encode in facade solution.  I'm
> > >curious about
> > >> the 2.3 clarifications you are referring to beyond the URI being the
> > >> "original".
> > >>
> > >> >
> > >> > - Someone with access to NES and/or IIS, could you please verify
> > >> > if the requestUri variable in NSAPI/ISAPI is encoded or
> > >not ? Neither
> > >> > of them seems to provide the choice between unencoded_uri and uri,
> > >> > so whatever they provide is the only thing we can use.
> > >>
> > >> I can try IIS easily enough.  I'll also try to get NES running and
> > >> see if I can determine this one too.  I'll need to do this at home,
> > >> so I'll report my results tonight.
> > >>
> > >> Larry
> > >>
> > >> >
> > >> > I think the result of the test with IIS/NES is essential
> > >to resolving
> > >> > this problem once and for all. If the URI they provide is the
> > >> > 'original/or
> > >> > encoded' - that's what we should use on Apache side.
> > >> >
> > >> > If not ( and the URI is decoded ) - that means the 'original uri'
> > >> > is un-implementable, and we shouldn't worry about it anymore, and
> > >> > using the decoded URI consistently is the best solution.
> > >> >
> > >> >
> > >> > Please, (I know there aren't too many windows user around :-),
> > >> > could someone check this ?
> > >> >
> > >> > Costin
> > >> >
> > >>
> > >
> >
>
>


*----*

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

Mime
View raw message