Hi Eric,
Some really, really great points here. My thoughts on some of them:
On 06/07/09 01:28, EricLaw wrote:
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.
I also haven't quite got this straight in my head.
I think it would be useful for the spec to contain a lot more detail on
what it hopes to achieve with the current versioning system - scenarios
where it would be useful, scenarios where it won't help, and so on - and
also why we decided not to put a version number in the CSP response itself.
Style-src
I don’t know what “style attributes of HTML elements” means.
It means <div style="some CSS here"></div>
frame-ancestors
In addition to IFRAMEs/FRAME tags, this should also restrict OBJECT
tags that point to HTML pages, correct?
I guess so :-)
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.
I'm sure we can do that, particularly if we have buy-in or tacit support
from multiple browser vendors. We are early in a Firefox development
cycle, so we do have time.
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.
The very existence of "meta" is now under discussion. But I think that
if we do implement a merging algorithm (which I think we should, albeit
for multiple headers) a "final" directive might be useful.
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?
Very good question.
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…
Another good one. Gut reaction: The things CSP is supposed to help with
are mostly connected with the page being loaded from a particular target
site. If it's no longer being loaded from that site, many of them go
away. So I think the answer is that CSP protection is removed. We
currently restrict HTML loaded from the local disk from accessing other
files on the local disk, but not in other ways.
Therefore, a site could specify “*.example.com” to match
“www.example.com” and “example.com”.
Hmm. For people not thinking, this would obey the Rule of Least
Surprise, but for people thinking, it would not obey that rule. <sigh>
Doesn’t make sense to me, because “self” is defined to include the
scheme. This suggests that we need a "selfhost" directive, which
includes the hostname only.
Or we make the same word serve two purposes, doing the "obvious" thing.
Parse Errors: Server detection
Parse errors are defined as only being reported on the client. This
is probably reasonable, but leads to the possibility that some UA will
fail to parse some CSP directive and the server operator will not know
about it.
Will this be a problem in practice, given that presumably the server
owner tests their site with a variety of UAs? We don't ping server
owners to say "your HTML is unparseable", after all. That would rather
increase the amount of traffic on the Internet! ;-)
If the “Fail closed” model is used, is there any way for the user to
know why the site is broken? Isn’t this going to create a problem,
where, say, a FF4 user will “downgrade” to a browser that doesn’t
support CSP (say, Opera 9) because the site “works properly there”?
Everyone loses.
This is a problem with a "tighten when the header is used, and then use
directives to loosen" approach. Content Restrictions had the opposite
approach - it started with loose (i.e. the situation as it is without CR
support) and tightened using directives. This avoided this problem. Of
course, both directions have pros and cons.
Agreeing with Sacolcor, I think the spec should explicitly note that
CSP isn’t intended to apply to User-Scripts, although I think the
Greasemonkey guys might find it hard to implement their current
feature-set considering where CSP is likely to be implemented in the
browser stacks.
We need to avoid breaking Greasemonkey/GreasemonkIE.
Scope Creep: exempt HEAD
We’ve had some folks suggest that CSP-like schemes would be more
easily deployed if they could allow arbitrary script/css to be
embedded inline/referenced in the HEAD tag.
Yes; CR originally had a way to allow this. I think it would make
converting sites quite a bit easier.
In particular, this could be used by non-JS responses to explicitly
prevent them from being used by SCRIPT tags, and to prevent HTML files
from being scraped by liberal CSS parsers. This is an anti-CSRF ASR.
I think using CSP should also mean that the scripts which are permitted
have to be served with the correct content type. As others have said,
this prevents people using E4X and some user content elsewhere in the
same domain to inject script which is actually an HTML page.
Scope Creep: Same Origin Only
The claim “Content Security Policy enables a site to specify which
sites may embed a resource” is currently over-broad, but it shouldn’t
be. (CSP currently seems to only apply to HTML documents, not
"resources" in general).
Yes, we need to think more about how CSP applies to non-HTML and
non-HTTP resources.
It seems natural that a subdownload should be able to say e.g. Content-
Security-Policy: callers<originlist> which would cause the UA network
stack to refuse to process (e.g. Set-Cookie) or return the content (to
a script tag, object tag, image tag, XHR request etc) unless the
Origin of the requestor matches the specified Origin list.
People have wanted the web to do this for years to prevent people
leaching e.g. image bandwidth, but I'm not convinced it would be a great
thing for the web. It seems to me that this sort of behaviour is a
regrettable side effect of an open web, but one we should just live with.
I’m not fully convinced that the “Origin” proposal (or at least the
versions I’ve read closely) will prove generally workable. Among
other problems, every protected resource would need to be served with
a Vary: Origin header, which is problematic for a number of reasons,
including legacy IE bugs (http://blogs.msdn.com/ieinternals/archive/
2009/06/17/9769915.aspx).
Presumably you've sent that feedback in the relevant direction?
---------------
Feedback from others
---------------
ASP.NET Controls
Apparently, ASP.NET controls are tightly bound to use of JavaScript:
protocol URIs, and this isn’t likely to be easily changed. For that
reason, it might be interesting to have a way to allow only those URIs
and not inline script blocks, event handlers, etc?
I know nothing about ASP.NET controls. Are these pre-built blocks of
HTML that can be included in a page when it's built with ASP?
I guess the question is: have we effectively blown up all the protection
if we allow javascript: URIs? Can every possible exploitation method be
adapted to use them?
Gerv
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
