RE: Nonce for CSS, Signature of script, link, img?


 With regard to hashes on external content, we already have a proposed deliverable for this in our new draft charter we're calling Sub-Resource Integrity, that could be easily be extended to content with a disposition of download.  Gervase Markham's "Link Fingerprints" proposal informed ours, and his was for exactly that use case.

 Regarding hashing inline content:

 1) Is there a straightforward canonicalization of inline content we can use to get an unambiguous hash?  

This proved to be quite challenging (actually, a total nightmare) with XML signatures.  Perhaps it is more easily achievable in the HTML DOM, but I'm not sure that's true.

2) Does a hash significantly improve security over just a nonce?  How and in what attack scenarios?

I can imagine injection scenarios that happen inside the context of a script block that is nonce tagged which a hash could theoretically prevent, but in practical terms, I wonder how the hash would be generated if the script block was intentionally dynamic?  Is there a meaningful way for the defender to use a hash to identify legitimate and intentional dynamic changes while excluding illegitimate injections?  I can't think of a method that offers any better protection than existing server-side input sanitization practices.

-Brad Hill

> -----Original Message-----
> From: Hendrik Brummermann []
> Sent: Wednesday, January 30, 2013 4:04 PM
> To:
> Subject: Nonce for CSS, Signature of script, link, img?
> The proposal for script-nonce made we wonder two things:
> First: Should we extend the concept to style definitions? If the style sheet is
> rather small, inlining will save a significant amount of time on the initial page
> load. For this reason many mobile providers already use Deep Packet
> Manipulation to embed external stylesheets.
> Second: Should we use a hash of the content? Static content such as
> JavaScript, CSS and images is often hosted on content delivery networks.
> With a hash in the <script>, <link>, and <img> elements, it can be ensured
> that these files have not been tampered with.
> Taking this one step further, this could be used to ensure that downloadable
> files, linked via an <a> tag, have not been manipulated.
> One of SourceForge's mirrors was recently compromised and served
> executables with a backdoor.
> For the use-cases listed above, an attribute in the elements will do.
> But we still want to ensure that injected content cannot do any harm. So we
> need to prevent an attacker from injecting an element with the correct hash.
> One idea to solve this, is to include the nonce value, which is transmitted in
> the CSP-header, into the hash function.
> Hendrik

Received on Thursday, 31 January 2013 00:21:24 UTC