You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Chris Bonk <bo...@gmail.com> on 2018/05/17 14:46:07 UTC
Tomcat 4.0.6 / 6.0.37 Struts 1.2.8 XSS CVE-2006-1548
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?
Thanks
Re: Tomcat 4.0.6 / 6.0.37 Struts 1.2.8 XSS CVE-2006-1548
Posted by Mark Thomas <ma...@apache.org>.
On 17/05/18 17:43, Chris Bonk wrote:
> 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)
It depends.
If you are using Tomcat's standard error page, then yes it is safe.
If you are using an application provided (custom) error page then it
will depend on how that page has been written.
If you use a Servlet container other than Tomcat and using the standard
error page mechanism you are probably OK but you should test it.
Mark
>
> 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 <bo...@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat 4.0.6 / 6.0.37 Struts 1.2.8 XSS CVE-2006-1548
Posted by Chris Bonk <bo...@gmail.com>.
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 <bo...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat 4.0.6 / 6.0.37 Struts 1.2.8 XSS CVE-2006-1548
Posted by Mark Thomas <ma...@apache.org>.
On 17 May 2018 15:46:07 BST, Chris Bonk <bo...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org