RE: [webappsec] UI Security, allow-from values

>Allowing multiple values will encourage some or many sites to put a large set of values into this header.
This cannot be understated.  Allowing a list here is likely to lead to bloated headers becoming commonplace.  It's just so easy to cut / paste another 500 domains into the master list a site serves for every single response.

>Unlike other CSP directives that allow multiple values for included content, those are likely to have a 
> small number of values, whereas ALLOW-FROM might routinely have hundreds or even tens of 
> thousands of possible valid values, so this is a different case where we need to encourage (force) a 
> different set of practices."
Completely agree.

>Allowing multiple values is necessary for multiply-nested frame use-cases.
FWIW, this should only be an issue with the full ancestor check scenario, not the top-level-only check.

>CSP already allows multiple values for most policies so any implementation complexity is already paid for.
Agree.

>My suggestion would be to allow for multiple values, but put non-normative implementation guidance 
>for policy authors suggesting that, while the EBNF doesn't set any hard limits on the number of origin 
>tokens valid for any policy, in practice user agent implementations will have limits on the number of 
>such tokens they will process, and that dynamic generation should be preferred over including a large 
>number of values.  
Entirely agree.  All things considered, I agree it makes the most sense to support the standard CSP syntax here.  I just wish there were even more of a way to set up incentives so we don't wind up with bloated headers becoming commonplace.

David Ross
dross@microsoft.com


From: Hill, Brad [mailto:bhill@paypal-inc.com] 
Sent: Tuesday, February 12, 2013 1:56 PM
To: public-webappsec@w3.org
Subject: [webappsec] UI Security, allow-from values

This resolves ACTION 118, and will be on the agenda for the 2/26 call after 2 weeks for discussion.

Where X-Frame-Options is currently implemented, and as specified at the IETF, the ALLOW-FROM directive allows only a single value.

As part of moving future, normative work on frame-options in to the UI Security draft, we have preserved this syntax restriction, (with the addition of allowing "self") but want to revisit it.

I hope that Tobias and David Ross will join this conversation to make their take on the issues explicit, but my best understanding of the two perspectives is:

Multiple-values: CON

Allowing multiple values will encourage some or many sites to put a large set of values into this header.  This will have potentially negative impacts on privacy, performance and implementation complexity.   Just as the CORS Access-Control-Allow-Access header allows only a single value, ALLOW-FROM should do the same and require dynamically generated responses.

Unlike other CSP directives that allow multiple values for included content, those are likely to have a small number of values, whereas ALLOW-FROM might routinely have hundreds or even tens of thousands of possible valid values, so this is a different case where we need to encourage (force) a different set of practices.

Multiple-values: PRO

Allowing multiple values is necessary for multiply-nested frame use-cases.
Allowing multiple values is consistent with other policies in CSP.
CSP already allows multiple values for most policies so any implementation complexity is already paid for.
The choice to dynamically generate vs. include multiple values is a privacy and performance cost primarily borne by resource owners, and should therefore be at their discretion. 

Side issue: Caching vs. dynamic generation?

Does forcing a single value (and hence dynamic generation of the policy) restrict or impact on the use-cases of CSP, e.g. prevent it from being used where caching is necessary.   I don't think this is the case, especially since we now allow combining multiple policy headers, but Tobias may be able to elaborate more here?


My suggestion would be to allow for multiple values, but put non-normative implementation guidance for policy authors suggesting that, while the EBNF doesn't set any hard limits on the number of origin tokens valid for any policy, in practice user agent implementations will have limits on the number of such tokens they will process, and that dynamic generation should be preferred over including a large number of values.  

-Brad Hill

Received on Friday, 22 February 2013 21:52:34 UTC