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

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 31 Aug 2009 21:17:42 -0700

(Sorry about the broken reply headers, I just joined the list and I'm  
replying from the archives. Also apologies for the duplicate copy to  
the individual recipients, I sent to the wrong list last time.)

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. 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.

I believe these two scenarios are relativel rare, and the vast  
majority of resources won't need to "Vary: Sec-From". 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.

> The latent problem here, BTW, is that some deployed cache
> implementations don't like Vary headers with any value other than
> 'Accept-Encoding', refusing to cache such responses. This means that
> Sec-From is going to negatively impact caching on the Web, potentially
> quite severely (i.e., some browser as well as intermediary caches
> won't work at all).
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.

Regards,
Maciej

---

From: Maciej Stachowiak <[email-masked]>
Date: Mon, 31 Aug 2009 21:44:18 -0700

(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,
>>>
>> 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.

>> 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.
>>
> Yes, but realise there are many shades of "uncacheable."
>
> 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