You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Bill Higgins <bi...@gmail.com> on 2009/04/27 22:52:13 UTC
Using encoded slashes safely
We have a servlet that acts as a proxy to other URLs from different
origins. E.g. via your web app you could get to the Google home page
via a URL like:
http://localhost/myapp/proxy/http%3A%2F%2Fwww.google.com%2F
Using this URL pattern, we immediately hit the Tomcat "noSlash"
restriction (Directory traversal CVE-2007-0450) and in order for our
proxy to work we have to set the environment variable
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH to true.
However, enabling this environment variable obviously opens us up to
the security vulnerability that CVE-2007-0450 intended to address
(being able to navigate to directories protected by the proxy's
content restriction).
The reason I'm writing is that I'm confused by the fix to
CVE-2007-0450. It seems like the fix was "Since Tomcat allows for
behavior that's not conformant with the URI spec (i.e. allowing
certain encoded characters to be treated as their reserved literal
equivalents), disallow those encodings globally". It seems like a more
appropriate solution would have been "Do not allow encoded backslashes
and slashed to be treated as their literal equivalents". This
alternative solution would have:
1) Removed the security vulnerability, and
2) Removed a "feature" that is outside the URI spec
It seems like the current solution disallows encoded characters that
are allowed by the URI spec in order to maintain behavior that is
outside the URI spec.
I have more questions on how to respond to this Tomcat behavior, but
I'm hoping someone could provide more input on the rationale behind
the current fix for CVE-2007-0450 to provide additional context for my
other questions.
--
Thanks,
- Bill Higgins (IBM Rational)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using encoded slashes safely
Posted by Tim Funk <fu...@joedog.org>.
IIRC, HttpServletRequest.getQueryString() should provide the query
string you desire.
-Tim
Bill Higgins wrote:
> On Tue, Apr 28, 2009 at 3:19 AM, Mark Thomas <ma...@apache.org> wrote:
>> Bill Higgins wrote:
>>> We have a servlet that acts as a proxy to other URLs from different
>>> origins. E.g. via your web app you could get to the Google home page
>>> via a URL like:
>>>
>>> http://localhost/myapp/proxy/http%3A%2F%2Fwww.google.com%2F
>>>
>>> Using this URL pattern, we immediately hit the Tomcat "noSlash"
>>> restriction (Directory traversal CVE-2007-0450) and in order for our
>>> proxy to work we have to set the environment variable
>>> org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH to true.
>> A better workaround might be to pass the required URL as a query parameter.
>
> Thanks for the idea. Although this breaks our current users, we're
> still in an early enough phase of development that they will probably
> be able to contain it.
>
> The only technical downside of this technique that I can see is that
> there appears to be no way to get the encoded content of a request
> parameter. When using the path, I could use
> HttpServletRequest.html#getRequestURI to get the encoded (or
> un-decoded) form of the URI but I see no similar capability for
> request parameters - any ideas?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using encoded slashes safely
Posted by Mark Thomas <ma...@apache.org>.
Bill Higgins wrote:
> 1) Do you consider the automatic decoding of encoded slashes to be a
> defect vs. the URI spec?
It looks like it based on my reading so far.
> 2) If so, do you think it would be worth it if I filed a bug report
> (or does one already exist)?
Please do. If there is a good reason for the current behaviour, this will
probably flush it out.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using encoded slashes safely
Posted by Bill Higgins <bi...@gmail.com>.
On Tue, Apr 28, 2009 at 3:19 AM, Mark Thomas <ma...@apache.org> wrote:
> Bill Higgins wrote:
>> We have a servlet that acts as a proxy to other URLs from different
>> origins. E.g. via your web app you could get to the Google home page
>> via a URL like:
>>
>> http://localhost/myapp/proxy/http%3A%2F%2Fwww.google.com%2F
>>
>> Using this URL pattern, we immediately hit the Tomcat "noSlash"
>> restriction (Directory traversal CVE-2007-0450) and in order for our
>> proxy to work we have to set the environment variable
>> org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH to true.
>
> A better workaround might be to pass the required URL as a query parameter.
Thanks for the idea. Although this breaks our current users, we're
still in an early enough phase of development that they will probably
be able to contain it.
The only technical downside of this technique that I can see is that
there appears to be no way to get the encoded content of a request
parameter. When using the path, I could use
HttpServletRequest.html#getRequestURI to get the encoded (or
un-decoded) form of the URI but I see no similar capability for
request parameters - any ideas?
>> I have more questions on how to respond to this Tomcat behavior, but
>> I'm hoping someone could provide more input on the rationale behind
>> the current fix for CVE-2007-0450 to provide additional context for my
>> other questions.
>
> I've been back over the private discussions that took place at the time. The aim
> was to provide a fix without breaking the existing functionality. There was no
> debate around changing the existing functionality, nor the correctness of it.
I certainly understand the need to not break users. However, just for context:
1) Do you consider the automatic decoding of encoded slashes to be a
defect vs. the URI spec?
2) If so, do you think it would be worth it if I filed a bug report
(or does one already exist)?
Thanks again for your help.
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
- Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Using encoded slashes safely
Posted by Mark Thomas <ma...@apache.org>.
Bill Higgins wrote:
> We have a servlet that acts as a proxy to other URLs from different
> origins. E.g. via your web app you could get to the Google home page
> via a URL like:
>
> http://localhost/myapp/proxy/http%3A%2F%2Fwww.google.com%2F
>
> Using this URL pattern, we immediately hit the Tomcat "noSlash"
> restriction (Directory traversal CVE-2007-0450) and in order for our
> proxy to work we have to set the environment variable
> org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH to true.
A better workaround might be to pass the required URL as a query parameter.
> I have more questions on how to respond to this Tomcat behavior, but
> I'm hoping someone could provide more input on the rationale behind
> the current fix for CVE-2007-0450 to provide additional context for my
> other questions.
I've been back over the private discussions that took place at the time. The aim
was to provide a fix without breaking the existing functionality. There was no
debate around changing the existing functionality, nor the correctness of it.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org