httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: Broken URI-unescaping in mod_proxy
Date Thu, 13 Sep 2007 14:45:06 GMT
On Sep 9, 2007, at 1:00 PM, Ruediger Pluem wrote:
> On 09/09/2007 04:30 PM, Nick Kew wrote:
>> On Sun, 09 Sep 2007 11:25:26 +0200
>> Ruediger Pluem <rpluem@apache.org> wrote:
>>
>>>
>>> On 09/09/2007 02:21 AM, Nick Kew wrote:
>>>> PR 41798 and many related ones (eg 39746, 38980 - both of which  
>>>> I've
>>>> closed today) show a history of incorrect URL-unescaping in
>>>> mod_proxy.
>>>>
>>>> For PR41798, the attached patch looks like a fix: it just uses
>>>> r->unparsed_uri (escaped) instead of r->uri (unescaped) in
>>>> proxy_trans.  I'm wondering if using unparsed_uri here risks
>>>> breaking something or has security implications we need to
>>>> consider, bearing in mind we already unescaped it and thus
>>>> verified it is well-formed.
>>> I think it has security implications, because
>>>
>>> 1. We do the proxy_walk *after* proxy_trans and the normal
>>> configuration expects that all the shrinking transformations  
>>> happened
>>> correctly.
>>
>> proxy_trans determines whether the request is to be ProxyPassed:  
>> if not,
>> the patch has no effect on the request.  The "filename" we just  
>> parsed
>> is not used locally, it's passed to the backend.  To pass it  
>> escaped is
>> indeed an RFC bug.
>>
>> As an additional safeguard, we already checked the incoming URL was
>> well-formed when we parsed r->uri.
>>
>>> 2. It can be used to circumvent ProxyPass / ProxyPassmatch  
>>> settings by
>>>    tricky encodings in order to sent requests to unintended  
>>> locations.
>>
>> How so?
>
> ProxyPass /a http://backend/
> ProxyPass /b http://backend/
>
>
> <Proxy http://backend/a>
>        allow from someip
>        deny from all
> </Proxy>
>
> <Proxy http://backend/b>
>        allow from someotherip
>        deny from all
> </Proxy>
>
> Request:
>
> GET /a/%2E%2E/b/somewhere
> GET /a/../b/somewhere
>
> This allows someip to access http://backend/b/somewhere with the  
> patch.
> It does not without because r->uri would be /b/somewhere.

Changes to the request URI must be referred back to the client in the
form of a redirect.  Any other choice will cause security holes in
the request chain, somewhere.

The proxy (when acting as a proxy) must not change the URI.

The reverse proxy (gateway) is just an origin server with a
stupid name -- it must send a redirect if it makes the above
change to a URI.

....Roy

Mime
View raw message