Hey Mark, I really appreciate your reply.
I can't see anything in the revision that specifically states sanitization however my Java isn't the best nor my software development with regards to what a "Valve" would be responsible for. I suspect that worrying about XSS at that level isn't a concern. Is it safe to assume that when passing a string Message to ServletException(message), that it can't be abused with embedded dangerous characters? Or is it dependant on how the exception is displayed (i.e. the template used for 500 errors) Cheers On Thu, 17 May 2018 at 11:46 Mark Thomas <ma...@apache.org> wrote: > On 17 May 2018 15:46:07 BST, Chris Bonk <bonk.ch...@gmail.com> wrote: > >Hello, > > > >I have a strange issue, I am trying to track down the root cause for an > >ancient CVE-2006-1548 > > > > > http://struts.1045723.n5.nabble.com/DO-NOT-REPLY-Bug-38749-New-XSS-vulnerability-in-LookupDispatchAction-td3510079.html > > > >I can replicate the XSS in Tomcat 4.0.6, however in Tomcat 6.0.37 the > >html > >characters needed to inject the script are properly encoded, what is > >the > >mechanism for this? I haven't been able to determine why > >ServletException > >handles the message parameter different between versioning. > > > >Can anyone point me in the right direction? > > Looks like the error handling was rewritten in 4.1.x. > > > http://svn.apache.org/viewvc/tomcat/archive/tc4.1.x/trunk/container/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java?view=log > > 286679 looks relevant. > > I'm on my phone so checking further is tricky but I suspect this is one of > those grey areas in the spec where it isn't clear if the webapp or the > container is responsible for sanitizing the data. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >