Hi Mark, Chuck,

Thanks for the explanation.

On checking found that, below system properties are set to true by our
application for a requirement.


                 org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH:
true


org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH: true



Is there any other workaround/solution which can help us make our
application secure w.r.t this vulnerability?


Thanks & Regards,
Aditi

On Wed, Nov 21, 2012 at 8:00 PM, Mark Thomas <ma...@apache.org> wrote:

> On 21/11/2012 13:40, Aditi Sinha wrote:
> > Hi,
> >
> > We have a web server hosted on Tomcat 7.0.22.
> >
> > There are two connectors defined server.xml listening at port 8080 and
> 8443.
> > During vulnerability scan a 3rd party tool reported  CVE-2007-0450
> “Apache
> > Tomcat Directory Traversal Attack” on both ports 8080 and 8443.
> > The tool was able to access the Tomcat manager application with the
> > following URL :
> > http://localhost:8080/scripts/\../manager/html
> >
> > As per Tomcat security documents the issue is not present in Tomcat 7.
>
> First of all, a clean Tomcat 7.0.22 install will return "400 Bad
> Request" if you try accessing that install.
>
> The problem is that "\" is not a valid character in a URL so Tomcat -
> rightly - complains.
>
> It is possible to get Tomcat to treat "\" as "/" by setting the
> following system property:
> -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true
>
> There is a reason that property is in the security section and that the
> default is "false". Setting it to "true" can have unexpected
> consequences (CVE-2010-0450) when Tomcat is used in conjunction with
> reverse proxies.
>
> If a value of "true" is used then Tomcat will retreat the URL above as
> http://localhost:8080/scripts//../manager/html
>
> which will be normalized to:
> http://localhost:8080/manager/html
>
> Given you appear to be accessing Tomcat directly, even with
> ALLOW_BACKSLASH=true this is not a directory traversal. It is a
> non-normalized URL that is being normalized which is perfectly normal.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Reply via email to