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

Re: Including the Javascript stack trace in the ContentSecurityPolicy report

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 02 Aug 2013 12:40:19 -0400
Message-ID: <51FBE0F3.6030007@mit.edu>
To: David Bruant <bruant.d@gmail.com>
CC: public-webappsec@w3.org
On 8/2/13 11:50 AM, David Bruant wrote:
> All the CSP rules have to be known by the runtime *before* any load

Yes....

> So I don't understand why asynchrony would be an issue.

Because implementations want to do the check of CSP rules asynchronously.

> In essence, an implementation can do (pseudo-JS code, lots of details omitted):
>
> function load(url){
>    if(url.violatesCurrentCSPRules()){ // sync because all rules are
> available. Has to be done anyway by a CSP conforming impl.

Sync with what?  Consider this script:


   var img = new Image();
   img.src = "http://whatever";

And implementation typically wants to do something like this in the 
setter for "src":

   postEventToImageLoaderThread(newURI);

then, asynchronously, things like security checks and CSP checks happen, 
I/O happens, etc.  For img.src things are actually a bit more 
complicated for compat reasons, but fundamentally implementations want 
to do as little work as possible on the main JS execution thread before 
returning from that src setter.

> The extra cost only occurs if a violation is detected which is expected
> to be a rare event.

The extra cost is that of either forcing CSP checks to be sync under DOM 
mutations or forcing DOM mutations to snapshot JS callstacks.

-Boris
Received on Friday, 2 August 2013 16:40:49 UTC

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