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