Re: rethinking caching

Benjamin Franz:
>
>On Sat, 16 Dec 1995, Koen Holtman wrote:
>> 
>>   Clients (including caching proxies) should disregard Location
>>   headers in 2xx responses if they do not point to the same server
>>   that generated the response.
>> 
>> This restriction still leaves you with a negotiation mechanism
>> powerful enough to handle the French/English example.
>> 
>> Note that the above solution assumes that either the content providers
>> on the same server either trust each other not to spoof, or that the
>> server has some Location response header filtering mechanism that
>> excludes spoofing.
>
>This is not a safe assumption. Numerous providers sell space to many 
>independent people on single servers. For example: www.xmission.com 
>serves on the order of 1000 independent entities, including many 
>businesses and people, and allows CGI to be owned by the individuals. 

The part `or that the server has some Location response header
filtering mechanism that excludes spoofing' above is supposed to cover
this situation.

Not that I expect many providers to implement such a filtering
mechanism, most would treat web spoofing like they treat news spamming
and mail forging now: forbid it in the terms of service agreement and
deal appropriately with any found violations.

Anyway, here is how a Location spoofing filter is supposed to work.
The HTTP server does some post-processing on all CGI output (except
for nph- scripts, I'll cover them later).  Part of this
post-processing includes calculating the Content-Length for the CGI
response.  In the same post-processing stage, the server could check
whether any Location headers generated by a CGI owned by Joe indeed
point to locations on the server controlled by Joe.  Depending on the
layout of the web space maintained by the server, this test could be
as easy as path prefix matching: i.e. the CGI under
http://www.xmission.com/joe/bin/blah is allowed to produce Location
headers to http://www.xmission.com/joe/doc.fr.html, but not to
http://www.xmission.com/john/info.html .  Another possibility, for
unix-based servers, is to compare the used-id's on the CGI executable
and the file or script pointed to.

As for nph- scripts: a non-trusting server administrator interested in
security would either disable them, or only allow them after auditing.

Of course, Shel's idea of making the cache key of a negotiated variant
be the pair (request-URI, location-URI) eliminates all spoofing risks,
we could switch to such a scheme if the consensus is that Location
header filtering is unfeasible.  Shel's scheme is safe no matter how
much the server administrator does about security, but has the
disadvantage of allowing less cache hits: it would be much more
difficult to let preemptive and reactive content negotiation share
cache slots for the variants.  [Note: an explanation of this last
statement would require a level of detail only appropriate in the
content negotiation or caching subgroups.]

>Clearly there is the opportunity for someone to spoof there under the 
>rule. It is not significantly safer than unrestricted redirections when 
>many (most?) people share common servers.

Unrestricted 3xx redirections are another issue entirely: unrestricted
3xx redirection will not allow Joe to fool a proxy cache into storing
a response from his script under John's URI.

I see the security issues connected to unrestricted 3xx redirects as
equal to the security issues connected to unrestricted <a href=..>
tags.  They are there, but there is nothing much we can do about them
beyond making users aware that web link titles may not be telling the
truth.

>Benjamin Franz

Koen.

Received on Sunday, 17 December 1995 03:12:47 UTC