W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2009

Re: The HTTP Sec-From Header (draft-abarth-origin)

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 31 Aug 2009 21:44:18 -0700
Cc: Adam Barth <w3c@adambarth.com>, ietf-http-wg@w3.org
Message-id: <7E1EF5D0-E07D-43B7-9311-C362BC842AE4@apple.com>
To: Mark Nottingham <mnot@mnot.net>

(Fixed list - my mistake originally).


On Aug 31, 2009, at 9:19 PM, Mark Nottingham wrote:

>
> On 01/09/2009, at 2:09 PM, Maciej Stachowiak wrote:
>
>>
>> (Sorry about the broken reply headers, I just joined the list and  
>> I'm replying from the archives.)
>>
>> Mark Nottingham wrote
>>> Adam,
>>>
>>> One thing -- AIUI Sec-From is sent with *all* requests, including  
>>> GET.
>>> Furthermore, servers will make security-related decisions about the
>>> response based upon it.
>>>
>>> As such, won't servers need to set
>>>
>>>  Vary: Sec-From
>>>
>>> in responses to asure that caches will do the right thing?  
>>> Otherwise,
>>> a cache could respond to a cross-site request with a stored response
>>> improperly.
>
>> I think servers will only need to set "Vary: Sec-From" if they  
>> actually gave a different response based on the Sec-From value.
>
> Yes.
>
>> This won't be the case for most resources retrieved with GET - only  
>> for (a) personalized resources that are cross-site accessible  
>> (which would likely also need to "Vary: Cookie" or  expire  
>> immediately for cache-correctness), or (b) for resources that are  
>> intended to be the target of GET-based form submissions, but which  
>> must be protected against CSRF, which are likely state-changing and  
>> therefore need to make themselves uncacheable.
>
> True. I suppose I was concerned because one way to implement this is  
> as a server plug-in (e.g., an Apache module), and if it's done that  
> way, it's going to be applied quite broadly. If a site applies it  
> with more precision (as you suggest), this won't be an issue, but I  
> can readily see someone coming up with a module and saying "just  
> deploy this on your server and you don't have to worry about CSRF."

You can't apply Sec-From in a totally generic way, since requests from  
URLs entered directly by the user, or from following links, will send  
"Sec-From: null". If the server needs to respond in these cases, and  
almost every server does, then it can't do any blanket rejection based  
on Sec-From values.

A more plausible module approach would be:
- Assume most GETs don't need CSRF protection, but allow the server  
administrator to opt in for particular URLs or URL patterns.
- Assume most POSTs (or other unsafe methods) do need CSRF protection,  
but allow the server administrator to opt out for particular URLs or  
URL patterns, for cases where cross-site POST is actually desirable.

>
>> I believe these two scenarios are relativel rare, and the vast  
>> majority of resources won't need to "Vary: Sec-From".
>
> True, but Vary does need to be pointed out in the draft.

Agreed.

>> The vast majority of resources on a typical site do not need Sec- 
>> From defense against GETs. In fact, resources retrieved by  
>> following links or directly typing a URL cannot rely on Sec-From at  
>> all.
>>
>> Furthermore, in both scenarios it's likely that the response myst  
>> already use a Vary header or otherwise be uncacheable.
>
> Yes, but realise there are many shades of "uncacheable."
>
>> I think that in practice, very few GET requests will be affected by  
>> this. Of those that are, likely they need to be uncacheable anyway.  
>> Thus, there will be very little impact to caching on the Web.
>
> I think I agree, with the proviso that this depends on how it's  
> deployed.

I think the deployment model where a Sec-From decision is made for  
nearly every resource is impractical for reasons stated above.

Regards,
Maciej
Received on Tuesday, 1 September 2009 04:51:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:10 GMT