On 02/09/12 23:40, Adam Barth wrote:
On Sun, Sep 2, 2012 at 4:40 AM, Tobias Gondrom
<[email protected]> wrote:
Hello all,
thank you for your feedback and input.
<hat="individual">
NIH (not invented here) should definitely never be reason for a decision -
in either way.
And I would also be open to assist the WebAppSec WG in writing this tiny bit
into CSP.
I have two main reasons why I think we should keep FO separate to CSP and
would like to hear your thoughts about it before we should make a decision.
(Please note that in the case of this topic I will obviously not be acting
as WG chair.)
1. Model and Semantic Reason:
Until now, I always understood the CSP model to be about "describe the
security policy for a loaded resource and say which parts of that content
you can execute and which references in that content you shall follow and
execute".
While the XFO/FO model is the reverse: describing for a resource, defining
by whom your resource may be framed/loaded from. In my view that was not a
natural part of the CSP model. And in my understanding that semantic
difference was also one of the reasons why it was not done in CSP1.0 in the
first place, but at the time agreed to be done in websec separately.
Now that we're done with CSP 1.0, I think it make sense to take a more
expansive view of the sorts of security policies that can be expressed
in a Content-Security-Policy. My view is that a security policy
expressed in CSP ought to have the following properties:
1) The policy should apply only to an individual resource
representation. That means that the security policy is scoped to the
individual HTTP response and doesn't have broader-reaching effects
(e.g., about future HTTP responses).
2) The policy should only restrict privileges---not grant any
privileges. That means that the security policy is useful for
implementing "least privilege": you can use it to drop privileges
you're not using (e.g., the ability to execute inline script) so that
an attacker can't trick you into using this privileges to your
detriment.
X-Frame-Options / Frame-Options fits nicely into this rubric.
Well. Hm. I am not sure that I would agree that extending the CSP
semantic model to the superset that then includes "defining by whom your
resource may be framed/loaded from" instead of the current CSP1.0 model
is necessarily a good thing. Maybe one question: If we extend the
semantic of a system, it is always good if such extension is not for a
group size of "1" (aka only one individual directive). Therefore my
question: Are there other use cases (directives planned for 2.0) that
require the same type of semantic extension or would FO be unique in
that regard? If so, which semantic extensions would that be?
Or as someone else from W3C WebAppSec wrote it more clearly to me about a
year ago:
"... removing frame-ancestors from CSP altogether if a better, standardized
Frame-Options is available to sites. In fact, it simplifies the model in
some ways since frame-ancestors is currently the only directive that
restricts content from the embedded site's perspective."
Having a simplified model has been very helpful to us over the past
year because it has let us finish CSP 1.0. Now we're done with CSP
1.0 and looking at what the next step should be in CSP's evolution.
2. Technical Implementation:
The current FO spec allows only one "Allow-From" URI. Which means that for
complex framing relationships, the FO header needs to be written/sent on the
fly on a per request basis.
My question is, what happens to only one "ALLOW-FROM" if we integrate it
into CSP?
Can we generate individual CSPs on the fly as well (including if a CSP
header references a file), or would this then implicitely mean we have to
allow a list of "ALLOW-FROM"?
Integrating with CSP imposes no technical restrictions in this regard.
If you want to have only a single source, you can define the syntax
as:
directive-name = "frame-options"
directive-value = source-expression
Most other directives use source-list (which is just a list of
source-expressions), but there's no reason we can't do something
different here if that makes sense. In fact, the only hard technical
restriction on the directive-value is that it conform to the following
ABNF:
directive-value = *( WSP / <VCHAR except ";" and ","> )
Adam, I am sorry. I may not have been clear enough with my question.
My concern is not with regard of whether we can define such a directive
(in my view this is trivial).
But the question is whether we can practically implement such, or
whether there are implementation problems that would forbid (or
seriously discourage) dynamic generation of a CSP on a per request
basis? Because that would be the consequence of only one single
"Allow-From" URI (instead of list).
Or to put it differently:
- Have there been successful and scaling implementations of CSP that
have generated the CSP header on the fly for every request?
- If not, what would be the pitfalls/problems if we would do so?
- What are possible performance issues with that?
- And last but not least, is there a caching of CSP use case? (which
could break if we generate the CSP file on the fly for every single
request...)
If we move FO to CSP, I would like to know whether this will break (or
due to implementation/scaling problems basically forbids) the current
design of "Allow-From" _before_ we do so.
(please note, that the initial version did allow a list for "Allow-From",
but there were serious concerns for performance in implementation for large
lists and privacy matters. The change to only one "Allow-From" is not
"written in stone", still I would like to understand if we limit ourselves
back to the "Allow-From list" implicitly by putting it into CSP? I had a
couple of private conversations on this problem in the last months, but they
could not definitively answer to that question...)
I'm a bit surprised that you'd want to limit frame-options to having
only one source-expression, but we can discuss that point regardless
of whether we decide to integrate it with CSP.
Actually, this was not my idea, but from Dave, who explained to me the
performance and privacy implications when going with a (potentially
long) list of allowed URIs. Personally, I could still see both ("list"
or "single" URI), though I can understand the very serious concerns with
"list".
We can discuss the FO design decision later, however, as explained
above, if the choice to move FO into CSP basically pre-decides that we
must then go with a "list" (for practical/implementation reasons), I
would like to know and spell out this limitation rather now than later.
Adam
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
