Re: [CSP] Clarifications on nonces

fwiw, I agree with part 1 and I would also love to be able to restrict
the powers of nonces to

a. Only work till DOMContentLoaded (which is another way, I think, of
saying what Brian suggested). The best I can think of right now is to
add a meta tag to script-src that is the same policy as the current
policy, but without the nonce.

b. Not be valid for external sources (i.e., only work for inline
script whitelisting).
---

Re the remaining two issues:  I am wondering if this is getting really
into esoteric territory now. Can you give an example of a server-side
XSS attack that could occur because the page wasn't fully generated
before the nonce was sent out to the client? I say server-side because
I agree with you that it would be nice to be able to lock down the
nonce to only work before DOMContentLoaded fires.

cheers
Dev

On 5 November 2014 18:48, Brian Smith <brian@briansmith.org> wrote:
> Hi,
>
> I noticed that the current draft says this about nonces: "If the policy
> contains a nonce-source expression, the server MUST generate a fresh value
> for the nonce-value directive at random and independently each time it
> transmits a policy. This requirement ensures that the nonce-value is
> difficult for an attacker to predict."
>
> I have one suggestion, one annoying comment, and one question regarding
> this:
>
> Suggestion: I think it would be useful to suggest that the nonce be
> generated with a cryptographically secure random number generator, and that
> the nonce be at least 128-bits long, before base64 encoding. Although
> obvious to all of us, I suspect that many people trying to use nonces will
> not have the background to create a proper nonce.
>
> Annoying Comment: "nonce" is not a great name for this construct, because
> technically the requirements for a CSP nonce are greater than the
> requirements for a nonce in normal usage of that word. But, it seems to be
> too late to change this.
>
> Question: Are the current requirements on nonces sufficient to ensure safe
> usage? I can think of three cases that make me think CSP nonce is not as
> secure as I would expect, but I think I may be overlooking something
> important:
>
> Case 1. Imagine that the web page contains a CSP nonce of X. Further, assume
> that the page uses XHR to retrieve HTML fragments from a server, and then
> inserts those fragments into the document. Further, assume that an attacker
> learns the value X (because CSP doesn't require X to be secret), and then
> inserts <script nonce=X> into that fragment retrieved via XHR. It seems like
> the attacker's XSS will succeed, despite CSP.
>
> It seems to me that it would be good to restrict CSP nonce so that it only
> works on static <script> elements, not on dynamically inserted ones, to
> avoid this, but I don't see that in the spec.
>
> Case 2: Imagine that the web page contains a CSP nonce of Y. Further,
> imagine that the web page is dynamically generated and that the server sends
> the headers and the first part of the page. Further, imagine that the second
> part of the page is dynamically generated and contains user-generated
> content from a database. If an attacker can learn the value Y between the
> time it is generated and the time when all the dynamic elements of the page
> have been built, it would be possible for the attacker to use a stored XSS
> attack to insert <script nonce=Y> into the second part of the page.
>
> It seems like it is important to recommend that the server not transmit any
> part of a response that uses script-nonce until the whole response page has
> been generated, and more generally require the server to not otherwise
> reveal the nonce value before the page is generated. Again, this is the kind
> of requirement that is common for cryptographic protocols, but which would
> be easy for a typical user of CSP to overlook, so explicitly suggesting this
> would be useful for ensuring safe(r) use of this construct.
>
> Case 3: A variation of Case 2. IIUC, it seems to me like violation reports
> transmit the violated directive and the whole policy. It seems like the
> nonce would be included at least once in the violation report. It would be
> amusing if an attacker could force a violation report to be sent before the
> page was finished loading, causing the browser to send the the violation
> report containing the nonce to the server, causing the server to insert the
> violation report into a database accessible to an attacker, where the
> attacker read the violation report from the database and used it to build an
> XSS that gets included in the page, because the page wasn't fully generated
> before the browser sent the violation report.
>
> Again, I'm not very familiar with CSP nonce, so I'm likely overlooking
> something that invalidates the concerns in cases 1-3, but I cannot figure
> out what it is. Help?
>
> Thanks,
> Brian

Received on Thursday, 6 November 2014 04:18:35 UTC