Re: Design issues for access-control

On 2007-10-31 16:26:38 +0100, Anne van Kesteren wrote:

> XMLHttpRequest POST allows more than <form> POST. 

Please elaborate.

> Servers will have to deal with cross-site <form> POST, but
> probably don't deal with cross-site XMLHttpRequest POST. As such,
> XMLHttpRequest POST is not guaranteed to be as "safe" as
> cross-site <form> POST is.

Please explain the differences from the perspective of the site that
needs to handle these requests, and explain how they are relevant
for the discussion at hand.

> Also, this makes it work for arbitrary method names, not just POST.

Fair point.  One question is, then, whether cross-site XHR
should be limited to GET and POST.

>> 2. What are our deployment scenarios?

>> The current specification on the one hand aims at being
>> lightweight on the server (therefore, the processing
>> instruction; therefore, the deny clause); on the other hand,
>> the processing model for non-GET requests involves a new HTTP
>> header (Method-Check or whatever it's called today) which
>> conveys a critical piece of information in an initial GET
>> request.  That's just plain inconsistent.

> Method-Check is done by the client. 

The If-Method-Allowed (or Method-Check) header is *set* by the
client.  That presumably happens so the server can evaluate it and
do something interesting.  If you don't expect any server-side
processing, please drop the header.

> Allow is done by the server. 

Allow is set by the server, yes, and becomes part of the client's
decision.  That actually adds new meaning to this header; we might
want to check the interaction with possible other uses.

> Non-GET requests are indeed more difficult, but since non-GET is
> already more complicated than just sending a reply (you have to
> do some more "advanced" processing on the server as a result of
> the request) I don't see this as a problem.

The main use case here is POST, which is deployed in existing
servers.  The additional header needs to be dealt with when it
occurs on a GET request.

Requiring special server-side processing for an existing method
means a significant change in terms of deployment scenario.

>> In particular, with the current model, and currently-deployed
>> servers, if a GET request for a resource returns an XML document
>> that includes an access-control processing instruction, then any
>> policy included in that document will spill over to permitting POST
>> requests for the same resource; mitigating that requires a change to
>> server behavior.

> No, because such content would not include an Allow HTTP header
> that allows that.

With the currently-specified use of the Allow header, such content
could include that header.  See RFC 2616, section 14.7.

>> Meanwhile, we also have a Referer-Root header of which we don't
>> say what it is supposed to mean or do.

> It allows you to not expose all the sites you make your content
> available to by just emitting the value from the Referer-Root
> header if you indeed allow that site.

So this is the second HTTP header that we expect to influence the
result of a GET request that isn't really a GET request?

> This is what using Allow solves. It has been suggested to use a
> new HTTP header for that purpose in case some servers have this
> header by default.  Given that you also need
> Access-Control/<?access-control?> I'm not sure if that's really
> worth it, but I'm open to feedback that suggests otherwise.

See above; the combination of Allow's current definition and the
processing instruction makes this a nasty trap.

>> Or do we assume that a certain amount of lightweight server-side
>> modification is in order, and that the access-control header is the
>> vehicle of choice?  If that's the case, I'd advocate dropping the
>> processing instruction and the deny clause along with it.  If (b) is
>> a goal, I'd also advocate to include per-method policies in the
>> language, and to drop the Method-Check (or whatever it's called
>> today) header.

>> (Incidentally, this choice has a side effect on the additional
>> exposure to some cross-site scripting vulnerabilities.)

>> I'm looking forward to talking more about this at TPAC.

> I hope the above clarifies the ideas. 

It clarifies some of the ideas, but it doesn't make the current spec
good.

> I also hope to find some time soonish to rewrite the draft.

Maybe wait with that till we're through this discussion. ;-)

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

Received on Wednesday, 31 October 2007 15:59:52 UTC