Re: [AC] Helping server admins not making mistakes

On 2008-06-10 16:51:29 -0700, Jonas Sicking wrote:

>>  - There needs to be a security consideration about Range, and not
>>    getting fooled by it -- since, frankly, the implementation you
>>    describe above is flawed.

> Which implementation is flawed?

An implementation of access-control that lets itself be fooled by
Range headers.

>>  - Can we get rid of the processing instruction already?

> I would actually be ok with that. But I know others have
> expressed a strong opinion to keep it.

>>  - Wouldn't be a problem if we went for a model in which the amount
>>    of flexibility in the client is minimal, effectively forcing
>>    developers to put the enforcement into the server.

> How is that?

Because (a) there wouldn't be a processing instruction, and (b)
enforcement in that model would seem to be less susceptible to weird
HTTP behavior.

In the current model, you need to make sure that server-side
implementations don't mess with headers in an unpredictable way; the
current approach is to attempt profiling the *requests* down to
something predictable.

There's also protecting the content of XML resources from being
tampered with by way of weird request construction.

Contrast that with a model in which you transmit relatively minimal
information in the HTTP request ("this is a cross-site request from
X", or "can you deal with cross-site requests" for the pre-flight),
and similarly minimal information in the repsonse ("ok to show to
the origin that you told me about").  In this model, the security
critical procesing is limited to evaluating one request header; the
failure modes for strange HTTP responses are limited to data not
being accessed -- i.e., the system fails safely.

>>> However we could obviously not apply the same fix if other
>>> custom headers have the same problem.

>> Indeed.  But maybe the fix here is really to drop the processing
>> instruction and rely on headers only.

> Right, but that would still only solve some of the dangerous
> server features I described. It wouldn't solve a header that
> stitches two resources together, or that allowed insertion of a
> custom header in the reply.

See above about the custom header; that kind of problem is inherent
to the current design.

In any event, there is no reason to believe that these effects are
limited to headers, and can't be generated by using exotic HTTP
methods, or using exotic query parameters that some whacky
server-side framework evaluates in an interesting way.  So it
strikes me that the vulnerabilities that you are defending against
mostly relate to server software that exhibits exotic behavior in
constructing HTTP responses.

If you're really worried about these kinds of attacks, then go for a
model (like what I described above) in which the enforcement happens
on the server side (possibly even within a web application firewall,
before hitting the server proper), and don't make the protection
depend on the HTTP response.

Cheers,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Wednesday, 11 June 2008 10:13:30 UTC