Return-Path: 
 <tomcat-dev-return-18942-apmail-jakarta-tomcat-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-tomcat-dev-archive@jakarta.apache.org
Received: (qmail 36214 invoked by uid 500); 17 Mar 2001 21:49:56 -0000
Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:tomcat-dev-help@jakarta.apache.org>
list-unsubscribe: <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
list-post: <mailto:tomcat-dev@jakarta.apache.org>
Reply-To: tomcat-dev@jakarta.apache.org
Delivered-To: mailing list tomcat-dev@jakarta.apache.org
Received: (qmail 36205 invoked from network); 17 Mar 2001 21:49:55 -0000
Message-ID: <018701c0af2b$e6301820$82deb018@intalio.com>
From: "Remy Maucherat" <remm@apache.org>
To: <tomcat-dev@jakarta.apache.org>
References: <Pine.BSF.4.21.0103171343340.90703-100000@localhost>
Subject: Re: cvs commit:
 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core
 StandardWrapperValve.java
Date: Sat, 17 Mar 2001 13:47:44 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N

> On Sat, 17 Mar 2001, Remy Maucherat wrote:
>
> > >   You can prove that it is not related to JSP by trying *any* URI that
> > >   includes JavaScript code, and triggers a 404, such as:
> > >
> > >
> >
http://localhost:8080/examples/<SCRIPT>alert(document.cookie)</SCRIPT>.xyz
> > >
> > >   The fix is to filter the message string included in the response, so
> > that
> > >   characters sensitive to HTML are rendered as their corresponding
escape
> > >   sequences (such as translating "<" to "&lt;") so that the browser
will
> > >   render them rather than execute them.
> >
> > I don't like that patch (sorry).
> >
> > AFAIK, '<' isn't a safe character in a URL. If encoded, it should be
encoded
> > using %xx.
> > So here, we should either :
> > - encode using %xx (instead of using the XML style encoding, because
> > otherwise after encoding the request will always fail with 404)
>
> But we already know the request failed with a 404.  If the web application
> actually had a resource named with the name above (unlikely but possible),
> it would have been handled in the usual manner.
>
> The filtering happens ONLY inside the standard error page that is
> reporting that fact.  It does NOT affect any other content.
>
> > - Refuse parsing unsafe characters in the connector, and return a 400
(bad
> > request); that would probably break some old clients
> >
>
> It's not the request parsing that is the problem -- it is the error
> reporting.

Hmmm, yes indeed. My mistake (I just finished reading the pages describing
this security problem). Also, I thought the filtering was before processing
(which isn't the case).

Remy