The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 |
Newsgroups: mozilla.dev.security
From: Gervase Markham <g...@mozilla.org>
Date: Mon, 06 Jul 2009 11:02:00 +0100
Subject: Re: Content Security Policy Spec questions and feedback
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 > Style-src It means <div style="some CSS here"></div> > I don’t know what “style attributes of HTML elements” means. > frame-ancestors I guess so :-) > In addition to IFRAMEs/FRAME tags, this should also restrict OBJECT > tags that point to HTML pages, correct? > W3C folks have been giving us (IE) a hard time about the number (and I'm sure we can do that, particularly if we have buy-in or tacit support > scattered documentation) of X- header names > http://blogs.msdn.com/ieinternals/archive/2009/06/30/Internet-Explore..., > 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.... > rather than using the X- prefix. from multiple browser vendors. We are early in a Firefox development cycle, so we do have time. > HTTP Header: Final The very existence of "meta" is now under discussion. But I think that > 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. 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 Very good question. > 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? > What happens to CSP if I save a CSP-protected document to my local Another good one. Gut reaction: The things CSP is supposed to help with > 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… 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. 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 Or we make the same word serve two purposes, doing the "obvious" thing. > scheme. This suggests that we need a "selfhost" directive, which > includes the hostname only. > Parse Errors: Server detection Will this be a problem in practice, given that presumably the server > 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. 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 This is a problem with a "tighten when the header is used, and then use > 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. 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 We need to avoid breaking Greasemonkey/GreasemonkIE. > 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. > Scope Creep: exempt HEAD Yes; CR originally had a way to allow this. I think it would make > 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. converting sites quite a bit easier. > In particular, this could be used by non-JS responses to explicitly I think using CSP should also mean that the scripts which are permitted > 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. 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 Yes, we need to think more about how CSP applies to non-HTML and > 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). non-HTTP resources. > It seems natural that a subdownload should be able to say e.g. Content- People have wanted the web to do this for years to prevent people > 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. 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 Presumably you've sent that feedback in the relevant direction? > 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). > --------------- I know nothing about ASP.NET controls. Are these pre-built blocks of > 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? 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 Gerv You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
| |||||||||||||