Talk:Security/CSP/Spec - Revision history

Gerv at 10:35, 8 October 2009

2009-10-08T10:35:39Z

Sidstamm: /* Version Beacon (CLOSED) */ no beacon, just future-expandable syntax

2009-10-01T16:45:57Z

Version Beacon (CLOSED): no beacon, just future-expandable syntax

← Older revision		Revision as of 16:45, 1 October 2009
Line 3:		Line 3:
	We've been discussing CSP in lots of places, mainly in the [http://groups.google.com/group/mozilla.dev.security mozilla.dev.security] newsgroup. This is a great spot to discuss details of the CSP Spec, though. I've split this page into topics and am marking each issue as either open or closed depending on whether we have made decisions to resolve it or not. -[[User:Sidstamm\|Sid]]		We've been discussing CSP in lots of places, mainly in the [http://groups.google.com/group/mozilla.dev.security mozilla.dev.security] newsgroup. This is a great spot to discuss details of the CSP Spec, though. I've split this page into topics and am marking each issue as either open or closed depending on whether we have made decisions to resolve it or not. -[[User:Sidstamm\|Sid]]

	== Version Beacon (<span style="color:~~green~~;">~~OPEN~~</span>)==		== Version Beacon (<span style="color:red;">CLOSED</span>)==

	Is more misuse of the user-agent header the best way to go, or does		Is more misuse of the user-agent header the best way to go, or does
Line 14:		Line 14:

	The alternative to the request announcing the support level is to version the reponse, and for the client to ignore policies with an unknown (newer) version. Combine that with server UA version sniffing if the server needs to decide which version of a policy to send. Or if we allow multiple CSP headers and intersect them (discussed elsewhere) then a server could simply send multiple versions which either get intersected into something sane in newer browsers or fall back to the older CSP header in older browsers. -dveditz		The alternative to the request announcing the support level is to version the reponse, and for the client to ignore policies with an unknown (newer) version. Combine that with server UA version sniffing if the server needs to decide which version of a policy to send. Or if we allow multiple CSP headers and intersect them (discussed elsewhere) then a server could simply send multiple versions which either get intersected into something sane in newer browsers or fall back to the older CSP header in older browsers. -dveditz

			I perceive general distaste for version strings in the UA header, so I am going to modify the spec to be forward-compatible: (1) unknown directives are not fatal -- they are just ignored (2) future versions can implement directives with arbitrary values, but directives in the first version of CSP are restricted to their existing syntax.

			Resolution: updated ABNF to allow future directives with arbitrary syntax.
			-[[User:Sidstamm\|Sid]]

	== Script Languages (<span style="color:red;">CLOSED</span>)==		== Script Languages (<span style="color:red;">CLOSED</span>)==

Sidstamm: /* frame-src Consistent Across Navigation (OPEN) */

2009-09-30T16:30:27Z

frame-src Consistent Across Navigation (OPEN)

← Older revision		Revision as of 16:30, 30 September 2009
Line 195:		Line 195:
	--duryodhan		--duryodhan

	== <tt>frame-src</tt> Consistent Across Navigation (<span style="color:~~green~~;">~~OPEN~~</span>) ==		== <tt>frame-src</tt> Consistent Across Navigation (<span style="color:red;">CLOSED</span>) ==

	The frame-src restriction does not appear to take navigation into account. Suppose example.com has a refresh.php that serves a page with a Meta Refresh (e.g., like http://www.wizards.com/leaving.asp?url=http://www.adambarth.com/ but		The frame-src restriction does not appear to take navigation into account. Suppose example.com has a refresh.php that serves a page with a Meta Refresh (e.g., like http://www.wizards.com/leaving.asp?url=http://www.adambarth.com/ but
Line 234:		Line 234:

	Once you XSS any page, can't you just XHR the a/c data page and get the data? Or you are saying that the A/C data page would have required the user to reenter his password ? I just think this case then becomes too contrived/obscure for CSP to take care off -- any such really sensitive page just shouldn't have a iframe from other page imho. --duryodhan		Once you XSS any page, can't you just XHR the a/c data page and get the data? Or you are saying that the A/C data page would have required the user to reenter his password ? I just think this case then becomes too contrived/obscure for CSP to take care off -- any such really sensitive page just shouldn't have a iframe from other page imho. --duryodhan

			I'm going to close this. I'll try to make it more clear in the spec that this is the case with frame-src (it is not eternally enforced), but I think a happy compromise enforces the frame-src policy on HTTP redirects (30x) while missing refreshes/js redirects.

			Resolution: Not changed. frame-src is enforced for HTTP redirects (30x).
			-[[User:Sidstamm\|Sid]]

	== <strike>video and audio src</strike> ==		== <strike>video and audio src</strike> ==

Sidstamm: /* Option (not source) Keywords (OPEN) */

2009-09-30T16:21:39Z

Option (not source) Keywords (OPEN)

← Older revision		Revision as of 16:21, 30 September 2009
Line 156:		Line 156:
	Using single quotes for 'none', 'inline', etc. -[[User:Sidstamm\|Sid]]		Using single quotes for 'none', 'inline', etc. -[[User:Sidstamm\|Sid]]

	== Option (not source) Keywords (<span style="color:~~green~~;">~~OPEN~~</span>) ==		== Option (not source) Keywords (<span style="color:red;">CLOSED</span>) ==
	Should we move the keywords 'inline' and 'eval' out of the script-src directive? ''YES''		Should we move the keywords 'inline' and 'eval' out of the script-src directive? ''YES''

Line 168:		Line 168:
	I added an "options" directive to the spec. Feedback please!		I added an "options" directive to the spec. Feedback please!
	-[[User:Sidstamm\|Sid]]		-[[User:Sidstamm\|Sid]]

			Resolution: using the "options" directive. See the spec.
			--[[User:Sidstamm\|Sid]]

	== <tt>form-action</tt> Directive? (<span style="color:green;">OPEN</span>) ==		== <tt>form-action</tt> Directive? (<span style="color:green;">OPEN</span>) ==

Sidstamm: /* origin/host/source terminology (OPEN) */

2009-09-28T23:37:33Z

origin/host/source terminology (OPEN)

← Older revision		Revision as of 23:37, 28 September 2009
Line 65:		Line 65:
	-[[User:Sidstamm\|Sid]]		-[[User:Sidstamm\|Sid]]

	== origin/host/source terminology (<span style="color:~~green~~;">~~OPEN~~</span>)==		== origin/host/source terminology (<span style="color:red;">CLOSED</span>)==

	Rather than using the term "host" and "source" would it be more accurate to replace all instances with "HTML5 Origin"? This term has a defined meaning and would remove ambiguity in cases (like report-uri) which are currently defined as both "same host" and "same source". -EricLaw		Rather than using the term "host" and "source" would it be more accurate to replace all instances with "HTML5 Origin"? This term has a defined meaning and would remove ambiguity in cases (like report-uri) which are currently defined as both "same host" and "same source". -EricLaw
Line 74:		Line 74:

	Gerv and I were talking about different things. He was not talking about treating all origin/host/source directives as applying to an entire subdomain but rather specifically about allowing the reportURI (and policyURI?) be anywhere on the "same domain" rather than strictly "same origin". I'm ok with publicSuffix+1 for the reportURI but uncomfortable with going beyond same-origin for the policyURI. But having the two directives have different restrictions is confusing. I'm open to arguments that looser restrictions on the policyURI is OK (or that we don't need the policyURI at all -- it complicates a lot of things) -dveditz		Gerv and I were talking about different things. He was not talking about treating all origin/host/source directives as applying to an entire subdomain but rather specifically about allowing the reportURI (and policyURI?) be anywhere on the "same domain" rather than strictly "same origin". I'm ok with publicSuffix+1 for the reportURI but uncomfortable with going beyond same-origin for the policyURI. But having the two directives have different restrictions is confusing. I'm open to arguments that looser restrictions on the policyURI is OK (or that we don't need the policyURI at all -- it complicates a lot of things) -dveditz

			Resolution: Requiring "same origin" for policyURI (scheme/host/port), and Public Suffix +1 for reportURI. --[[User:Sidstamm\|Sid]]

	== What does 'self' represent? (<span style="color:red;">CLOSED</span>)==		== What does 'self' represent? (<span style="color:red;">CLOSED</span>)==

Duryodhan: /* form-action Directive? (OPEN) */

2009-08-12T23:56:50Z

form-action Directive? (OPEN)

← Older revision		Revision as of 23:56, 12 August 2009
Line 185:		Line 185:
	Also, <tt>form-action</tt> is not part of the spec yet... but the more it is discussed, the more I'm starting to think it's useful.		Also, <tt>form-action</tt> is not part of the spec yet... but the more it is discussed, the more I'm starting to think it's useful.
	-[[User:Sidstamm\|Sid]]		-[[User:Sidstamm\|Sid]]

			I agree :). In addition, in the spec could you please clarify that the CSP is only applied to automatic HTTP requests and not those caused by User interaction (as I noted before)? I honestly thought that it applies to all HTTP requests.

			--duryodhan

	== <tt>frame-src</tt> Consistent Across Navigation (<span style="color:green;">OPEN</span>) ==		== <tt>frame-src</tt> Consistent Across Navigation (<span style="color:green;">OPEN</span>) ==

Duryodhan: /* frame-src Consistent Across Navigation (OPEN) */

2009-08-12T23:51:39Z

frame-src Consistent Across Navigation (OPEN)

← Older revision		Revision as of 23:51, 12 August 2009
Line 222:		Line 222:

	-[[User:Sidstamm\|Sid]]		-[[User:Sidstamm\|Sid]]


			Once you XSS any page, can't you just XHR the a/c data page and get the data? Or you are saying that the A/C data page would have required the user to reenter his password ? I just think this case then becomes too contrived/obscure for CSP to take care off -- any such really sensitive page just shouldn't have a iframe from other page imho. --duryodhan

	== <strike>video and audio src</strike> ==		== <strike>video and audio src</strike> ==

Sidstamm: /* form-action Directive? (OPEN) */

2009-08-12T22:38:38Z

form-action Directive? (OPEN)

← Older revision		Revision as of 22:38, 12 August 2009
Line 182:		Line 182:

	So either we need a directive to control form actions, or we shouldn't subject the form actions to CSP at all like anchor-based links (not even the allow directive).		So either we need a directive to control form actions, or we shouldn't subject the form actions to CSP at all like anchor-based links (not even the allow directive).

			Also, <tt>form-action</tt> is not part of the spec yet... but the more it is discussed, the more I'm starting to think it's useful.
	-[[User:Sidstamm\|Sid]]		-[[User:Sidstamm\|Sid]]

Sidstamm: /* form-action Directive? (OPEN) */

2009-08-12T22:35:55Z

form-action Directive? (OPEN)

← Older revision		Revision as of 22:35, 12 August 2009
Line 178:		Line 178:

	Additionally, in this scenario, while I do understand where you are coming from - there is a difference between links and forms. In links more often than not, you(user) know where you are going to. In forms unfortunately there is no indication in current UI of where the form data is going. So although there is user interaction in a form submission, whether user intent is there or not, is not clear. As such, I think forms should be covered by allow directive. If not, then a form-src also makes sense. --duryodhan		Additionally, in this scenario, while I do understand where you are coming from - there is a difference between links and forms. In links more often than not, you(user) know where you are going to. In forms unfortunately there is no indication in current UI of where the form data is going. So although there is user interaction in a form submission, whether user intent is there or not, is not clear. As such, I think forms should be covered by allow directive. If not, then a form-src also makes sense. --duryodhan

			Assume form actions are subject to the <tt> allow</tt> directive as you recommend. If a site wants to allow form submissions to arbitrary third party sites (such as search boxes with arbitrary targets), then they have to open up the allow directive to be something like <tt>allow *</tt>. This is not safe, especially if the site authors don't want ActiveX controls or Scripts loaded from third party sites. As a result, the site authors have to then use the rest of the directives as ''blacklists'' instead of whitelists, making the policy a bit more confusing. If there's a <tt>form-action</tt> directive, then only one additional directive is needed aside from <tt>allow self</tt> to get a fairly closed-down policy that allows form submissions to arbitrary sites.

			So either we need a directive to control form actions, or we shouldn't subject the form actions to CSP at all like anchor-based links (not even the allow directive).
			-[[User:Sidstamm\|Sid]]

	== <tt>frame-src</tt> Consistent Across Navigation (<span style="color:green;">OPEN</span>) ==		== <tt>frame-src</tt> Consistent Across Navigation (<span style="color:green;">OPEN</span>) ==

Sidstamm: /* javascript: URIs by user */

2009-08-12T22:29:17Z

javascript: URIs by user

← Older revision		Revision as of 22:29, 12 August 2009
Line 237:		Line 237:

	I am not sure either :). But I think as a spec, the document should think about these corner cases and clearly write out the expected behaviour. --duryodhan		I am not sure either :). But I think as a spec, the document should think about these corner cases and clearly write out the expected behaviour. --duryodhan

			Let me clarify -- I'm not sure if bookmarklets are deployed as user scripts or content scripts in various pieces of software (browsers). I haven't checked how different browsers behave. It '''is''' clear that user-provided scripts should not break (as per the CSP spec). I'm pretty sure "user provided" would include bookmarklets, since they're initiated by the user. I'll add the word "bookmarklets" to the spec to make this more explicit.
			-[[User:Sidstamm\|Sid]]