- From: Mountie Lee <mountie.lee@mw2.or.kr>
- Date: Thu, 31 Jan 2013 09:31:32 +0900
- To: "Hill, Brad" <bhill@paypal-inc.com>
- Cc: Hendrik Brummermann <nhb_web@nexgo.de>, "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAE-+aYKxEFKrWkdkzxNYOHwHGKi7AgxzdeAUPur=JKmPH8YPJA@mail.gmail.com>
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 UTC