Re: [access-control] non-GET threat model and authorization choreography

* Ian Hickson wrote:
>Method-Check is needed to distinguish invokations intended to just check 
>whether a POST (or whatever) is safe, from invokations intended to get the 
>actual resource. If a resource would do a lot of work on a GET normally, 
>we don't want it to have to do a lot of work when the UA is going to 
>ignore all but the headers and the prologue.

Why can't you use Referer-Root for this purpose? Clearly though this
will lead to authors sending the Allow header only if you specify the
Method-Check or Referer-Root header in the request, so you would have
to deal with a number of caching problems to get this right. You'd be
better off if, say, you specify a redirect to the resource you'd want
to send out for GET requests (but see below), or if you use OPTIONS.

>We can't use OPTIONS because Apache returns
>
>   Allow: GET,HEAD,POST,OPTIONS,TRACE
>
>...by default, which would basically mean that out of the box, any 
>resource that support cross-site GET would automatically support 
>cross-site POST.

My understanding is that you don't think the check is necessary for
POST, so this issue would seem moot? You are also mistaken about the
default; Apache does this only for static files, and sending a POST
in that case would have no effect. If you want to handle the posted
data, you would use methods like CGI and PHP scripts to do that, and
in that case Apache won't send any Allow header on its own, so you
might get incorrect information in some cases, but nothing bad will
happen.

>Also, OPTIONS doesn't return a body, which is useful to authors who want 
>to include the cross-domain rights in XML PIs rather than HTTP headers.

I am not sure why OPTIONS does not return a body? Some servers might
not send one in some cases, but e.g. if you are using Apache and the
PHP module, you'll actually have to stop it from sending a body. HTTP
certainly allows sending a body. But I don't see the point either way,
you have to set the Allow header correctly, so you can use the header.

Why then would you use the processing instruction instead, and why is
providing this convenience more important than ensuring that the check
completes quickly and wastes little resources? It seems the draft con-
siders it out of scope to define how you'd deal with redirects for the
GET request, so we'd have per-specification rules for that. Why does
this convenience option warrant the additional complexity?

>We need the server to have access to the source's "origin" (scheme-host- 
>port) so that if the host has an ACL that is longer than conveniently 
>transmittable via headers (or, for that matter, if the list is somewhat 
>sensitive, like a list of paying customers) the host doesn't have to send 
>the entire list each time, and can instead just check the header for which 
>host is being tested, just returning that one.

>Passing the origin information in the URI on a per-origin basis would be 
>technically possible but has much higher costs in terms of author 
>education (instead of being able to copy-and-paste code from site to site, 
>authors would have to actually change each URI being fetched). This 
>doesn't scale well in environments like common libraries using this kind 
>of feature.

You can do all of this using the Referer header and other methods (like
passing origin information in the ultimate request). This has a certain
convenience factor and success rate. What I don't understand is when you
need something slightly better and why disclosing this information needs
to be the default.

The service provider will always have some amount of unwelcome requests
it has no choice but to service (automated requests spoofing the Referer
header, for example) so you might aswell deal with Referer-less requests
as if they had an accepted Referer. That embedding the service fails for
certain sites for all clients sending a proper Referer would seem to be
a sufficient deterrent. So I still don't see why this header is needed.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

Received on Tuesday, 16 October 2007 05:36:11 UTC