(I'm moving a thread to NNTP at the request of Gerv. Thanks for
reading!)
The following is a weakly-organized list of my questions and thoughts
on the current CSP spec draft. (See
http://blogs.msdn.com/ie/archive/2009/06/25/declaring-security.aspx
if you're interested in higher-level feedback)
---
Versioning
---
Server CSP Versioning
Can the server define which version of CSP policies it wants to use,
allowing the client to ignore? I know that backward compatibility is
the goal, but other successful features (E.g. Cookies) have had tons
of problems here as they try to evolve. The current “Handling parse
errors” section imposes a number of requirements that might be onerous
in the distant future when we’re on version 5 of the CSP feature.
User-Agent header
What’s the use-case for adding a new token to the user-agent header?
It’s already getting pretty bloated (at least in IE) and it’s hard to
imagine what a server would do differently when getting this token.
---
Policy Questions
---
Style-src
I don’t know what “style attributes of HTML elements” means. Is this
meant to cover cases where a CSS rule specifies url() for a font/
cursor/image? Or are those meant to be controlled by the other
relevant CSP directives?
frame-ancestors
In addition to IFRAMEs/FRAME tags, this should also restrict OBJECT
tags that point to HTML pages, correct?
What exactly an “ancestor” is should probably be defined here.
I like this directive, but it’s worth noting that this is the only
directive which constrains how others can host the protected-
document. More on this later (see Scope Creep below).
---
CSP Declarations
---
HTTP: Header Name
W3C folks have been giving us (IE) a hard time about the number (and
scattered documentation) of X- header names
http://blogs.msdn.com/ieinternals/archive/2009/06/30/Internet-Explorer-Custom-HTTP-Headers.aspx,
and they’ve strongly encouraged us to register our header names (even
provisionally) with IANA
http://www.iana.org/assignments/message-headers/message-header-index.html
rather than using the X- prefix. You don’t need a formal RFC to do
this (some just point to the relevant working groups), and you’ll find
some of the header names proposed by Jackson and Barths listed there
already. I think Content-Security-Policy is well-thought-out enough
that it’s going to get implemented by more than one UA, and we might
as well save a few terabytes of traffic over the next several years by
dropping the X-. Mark Nottingham (HTTPBis chair, I think) is probably
a great person to talk to about this if you want more info on best
practices for header definition.
HTTP Header: Final
It seems like it might be useful for a CSP Header to declare that it’s
the “Final” security policy, to prevent meddling by META Header
injection and the like. Of course, HTTP Header injection is a threat
as well, but that seems like a smaller threat, and the “FINAL”
directive doesn’t really significantly increase attack surface here
because sites using the Header are unlikely to also send the META tag.
Meta Tag Placement
I like the restriction that META must appear within the HEAD, although
technically HTML5 has no such restriction.
Are relative URIs valid for the report-URI/policy-URI? (Seems like
this would be a good thing to support). However, if so, is there any
interaction/relationship with the BASE tag, which is supposed to also
appear early in the head?
The spec needs to specifically define what happens if a META tag is
found in violation of the rules (e.g. It MUST be ignored, and a
CONSOLE ERR must be raised)
CSP-Tagging
What happens to CSP if I save a CSP-protected document to my local
disk? I’d assume it would be ignored (because many restrictions could
be broken) but this should be explicit. Also, when saving docs to
disk, HTTP headers are lost, so to preserve it, you’d need to
explicitly serialize to a META tag, which could get complicated if the
document already had a CSP META…
---
Policies and Wildcarding
---
Wildcarding: Multiple Labels
Allowing a wildcard to represent an unlimited number of DNS labels
could be problematic, because it leaves the wildcard-configured site
at the mercy of the DNS policies of any of its children. I think
there’s a use case that suggests a single-label wildcard would be
useful but a multiple-label wildcard incurs unneeded attack surface
for some.
The “how many labels can * represent” problem has come up in a number
of contexts, including Access-Control and HTTPS certificate
validation. In the latter case, * is defined in RFC2818 as one DNS
label, but Firefox does not currently follow that RFC.
Wildcarding: Zero Labels
In a related vein, wildcards are currently defined as “one or more
labels” by the CSP spec. Real-world sites have the unfortunate habit
of serving content from both “example.com” and “www.example.com” which
is likely to cause site breakage
