W3C home > Mailing lists > Public > public-webappsec@w3.org > January 2013

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

From: Mountie Lee <mountie.lee@mw2.or.kr>
Date: Thu, 31 Jan 2013 09:31:32 +0900
Message-ID: <CAE-+aYKxEFKrWkdkzxNYOHwHGKi7AgxzdeAUPur=JKmPH8YPJA@mail.gmail.com>
To: "Hill, Brad" <bhill@paypal-inc.com>
Cc: Hendrik Brummermann <nhb_web@nexgo.de>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi.
in WebCrypto WG UseCase,
similar concerns were raised.
and hash verification were suggested (
https://dvcs.w3.org/hg/webcrypto-usecases/raw-file/tip/Overview.html#data-integrity
)

but the usecase example uses "eval()" which is not recommended.

please share the link for "Sub-Resource Integrity" and related information.

regards
mountie.



On Thu, Jan 31, 2013 at 9:20 AM, Hill, Brad <bhill@paypal-inc.com> wrote:

> Hendrik,
>
>  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 [mailto:nhb_web@nexgo.de]
> > Sent: Wednesday, January 30, 2013 4:04 PM
> > To: public-webappsec@w3.org
> > 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
>
>
>
>
>
>
>
>
>


-- 
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 2140 2700
E-Mail : mountie@paygate.net

=======================================
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World
Received on Thursday, 31 January 2013 00:32:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 31 January 2013 00:32:16 GMT