- From: Daniel Veditz <dveditz@mozilla.com>
- Date: Thu, 27 Jan 2011 10:35:18 -0800
- To: Michal Zalewski <lcamtuf@coredump.cx>
- CC: Brandon Sterne <bsterne@mozilla.com>, public-web-security@w3.org
On 1/27/11 9:57 AM, Michal Zalewski wrote:
> plus, there are some types of content loads that are not covered by
> these categories (say, favicon).
Borderline: favicons aren't "in" the page, but if you're worried
about exfiltration then it's a problem that they are linked to by
the page. If we agree they should be covered it should be lumped
with images and say it's a Firefox bug they aren't enforced.
prefetching might have a similar exfiltration risk -- should the
presence of a CSP header disable it?
> The catch-all category is confusing, probably.
It is, but when you take it out you only have to try to write a few
policies for real sites before you desperately want it back.
> 1) Make it less granular, and group content types by their security
> impact: have one class for passive multimedia, one for nested
> documents, and another for scriptable content?
We oscillated several times between lumpy and granular. Fewer
classes (simpler) is always more attractive, easier to explain and
understand. The danger is that future features then end up being
added to the existing lumps, possibly enabling things that the site
isn't aware they need to now filter. It's a constant problem as we
expand the capabilities of browsers -- sites that used to be
perfectly secure are suddenly hackable because all the new browsers
added feature-X.
On the other hand, if in practice sites rely on the default
("allow") simplification for most content anyway then they sort of
have that problem. That would be an argument for removing the
default directive, forcing people to write more verbose policies,
which then screams out for less granular controls. Back to the
beginning, start the cycle all over again.
> 2) Make it more granular but simply tie it to the relevant tag name.
> So, we could have allow[img] = ..., allow[embed] = ..., etc. This is
> more immediately extensible, and allows unrecognized rules to be
> skipped more confidently.
Attractive from an educational point of view, easy to understand.
Your <xxx> didn't load because you didn't add an allow[xxx] policy.
I'd say "feature name" rather than "tag name". XHR isn't a tag, nor
is font-face.
> I think there are cases where people would want to enforce the rest of
> their policy strictly, but only be notified on frame-ancestors
> violations (by DOM or on server-side).
Not that this should be part of the spec necessarily but in Firefox
you could have two separate policies: an enforced one without the
frame-ancestors and a report-only one with the frame-ancestors bit.
-Dan Veditz
Received on Thursday, 27 January 2011 18:35:59 UTC