W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2012

Re: Line numbers in Content Security Policy reports

From: Ian Melven <imelven@mozilla.com>
Date: Tue, 18 Dec 2012 09:45:38 -0800 (PST)
To: Mike West <mkwst@google.com>
Cc: public-webappsec@w3.org, dveditz@mozilla.com, Tanvi Vyas <tanvi@mozilla.com>, Neil Matatall <neilm@twitter.com>
Message-ID: <619903236.1540980.1355852738355.JavaMail.root@mozilla.com>

Hi Mike,

at the moment our CSP implementation sends the name of the source file, a sample
of the content (as Neil has outlined) and the line number. The line number and name
of source file are not always available, but are sent whenever they are.

Is the concern around being able to identify addons a user has installed mainly
around fingerprinting using the set of addons or more that the presence of the addon
itself may be 'incriminating' in some way ? 

We also currently (not per spec) restrict reports to being send to TLD+1 as a
small mitigation wrt the concerns around privacy or providing useful information to an attackers.
I have heard complaints about this from sites who have deployed CSP, particularly since
this restriction is specific to Gecko AFAIK.


----- Original Message -----
From: "Mike West" <mkwst@google.com>
To: "Neil Matatall" <neilm@twitter.com>
Cc: public-webappsec@w3.org, dveditz@mozilla.com, "Tanvi Vyas" <tanvi@mozilla.com>, "Ian Melven" <imelven@mozilla.com>
Sent: Tuesday, December 18, 2012 6:50:28 AM
Subject: Re: Line numbers in Content Security Policy reports

Thanks Neil! 

In the general case, I think this is a good idea. I'm not convinced that giving you X characters of context is helpful, but a line-number (or perhaps a function name or call stack?) would probably be quite useful. 

The only complication I see is the potential privacy impact of revealing code that an extension or add-on has injected. Ideally, of course, extensions would bypass a page's CSP, but that isn't currently the case, despite ongoing work in that direction. 

Are there other objections to adding this sort of context? Dan, Tanvi, Ian, perhaps you could give some feedback regarding Mozilla's current implementation, which does provide some of this information already? 



Mike West < mkwst@google.com >, Developer Advocate 
Google Germany GmbH, Dienerstrasse 12, 80331 M√ľnchen, Germany 
Google+: https://mkw.st/+ , Twitter: @mikewest, Cell: +49 162 10 255 91 

On Fri, Dec 14, 2012 at 11:50 AM, Neil Matatall < neilm@twitter.com > wrote: 

If inline script is disallowed and I receive a report saying that the script-src directive was violated which indicates javascript has been injected (or pre-existing) on a page, I would like to know where the code lives. Knowing this can help you determine where your existing inline script lives as well as give you hints as to how the script may have been injected if no inline script was expected. 

I would like to propose that we add the line number as part of the 1.1 spec. Thoughts? 
Received on Tuesday, 18 December 2012 17:46:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:30 UTC