Re: Line numbers in Content Security Policy reports

Hi,

likewise response inline :)

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

> Hey Ian, response inline. 

> On Tue, Dec 18, 2012 at 9:45 AM, Ian Melven < imelven@mozilla.com > wrote: 

> When would a line-number not be available? In theory it should be possible to grab a line number from script executing inline on a page, or of the call to `eval` that triggered whatever code violated the policy. 

right - we always have the line number in those cases. It looks like we don't have it when there's a frame ancestors
violation, which is not in the spec but still in our implementation (we don't plan to remove it currently), or
when the violation is not an inline/script eval violation.

> I'm a little wary of grabbing text of the JavaScript file and passing it on, especially in the context of JS injected by addons, which generally tend to think of their code as private, and often aren't shy 
> about hardcoding tokens and other secrets. 

this seems like a valid concern to me. 

> How much value is there in getting some number of characters above and beyond a line number or function name/stack? 

good question. I would think the line number/file or function name/stack would go a long way here, perhaps
if the script is dynamically generated or minimized etc. they may not be as useful though, although
in these cases I'm not sure a script sample would help either. This is somewhere where
feedback from those implementing CSP on sites would be helpful :) 

>>  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 ? 

> Both, plus the question of hard-coded secrets above. To whatever extent reasonable, CSP should get out of the way of user-installed extensions and addons. 

> This isn't a problem specific to sampling the script, of course. It's a general concern. 

indeed, i agree.

>> 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. 

> Interesting. Are you seeing implementers with external report collection servers, or just running their own servers on external domains? 

Unfortunately i don't have the specific details, just that the implementer had to create essentially CSP report forwarders
on their sites to be able to get the reports to where they wanted them - this is another area where feedback to the WG from implementers
would again be illuminating.

thanks,
ian

Received on Tuesday, 18 December 2012 18:51:46 UTC