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

Re: CSP, unsafe-eval and crypto.generateCRMFRequest

From: Ian Melven <imelven@mozilla.com>
Date: Mon, 7 Jan 2013 10:03:51 -0800 (PST)
To: Adam Barth <w3c@adambarth.com>
Cc: public-webappsec <public-webappsec@w3.org>
Message-ID: <2019458146.4975880.1357581831448.JavaMail.root@mozilla.com>

Hi Adam,

welcome back :)

----- Original Message -----
From: "Adam Barth" <w3c@adambarth.com>
To: "Ian Melven" <imelven@mozilla.com>
Cc: "public-webappsec" <public-webappsec@w3.org>
Sent: Saturday, January 5, 2013 1:26:42 PM
Subject: Re: CSP, unsafe-eval and crypto.generateCRMFRequest

> My understanding is that generateCRMFRequest isn't mentioned because
> it's a Mozilla-proprietary API.  However, your point about the spec
> being overly explicit is a good one.  Maybe we should add some text
> about the intent behind 'unsafe-eval' so it's easier for folks to
> decide how to treat future/proprietary APIs? 

that sounds like a good idea to me. Overall, I think the spec could use
more statement of intent for various things that CSP tries to restrict - 
this would have helped our inline styles implementation, for example.

> We can also add some informative text about generateCRMFRequest if that would be useful to
> you.

well, we already know we have to block it :) we could use it as an example in the 
general unsafe-eval guidance perhaps.. 


On Fri, Dec 28, 2012 at 9:51 AM, Ian Melven <imelven@mozilla.com> wrote:
> Hi,
> recently Paul Theriault discovered that in Gecko, crypto.generateCRMFRequest bypasses CSP by
> allowing script execution from a string when unsafe-eval isn't specified as part of
> an applied CSP.
> this has been filed as http://bugzilla.mozilla.org/show_bug.cgi?id=824652
> there was a suggestion in the bug to add this to the list of eval and friends
> blocked by CSP in the spec - i think in general the spec avoids exhaustively listing
> all the ways to do things such as eval, but am bringing this up here to see if others
> think we should call out this case since it seems like a fairly
> easy one to miss.
> thanks !
> ian
Received on Monday, 7 January 2013 18:04:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:00 UTC