tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardWrapperValve.java
Date Sat, 17 Mar 2001 21:46:26 GMT


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.

> Remy
> 
> 

Craig



Mime
View raw message