Re: Line numbers in Content Security Policy reports

Perhaps I should explain my reasoning behind asking for these two
features, perhaps I'm just thinking of the problem in the wrong way.

We aggregate all of our CSP reports for analysis. An script-src
violation triggered by inline code in Webkit produces a meaningless
report without the sample/line number. I visit the page in question,
don't see the same result, and it makes me sad. It is impossible to
determine if this is a false positive.

On Firefox, the reports contain enough information for me to say "this
came from an extension" or otherwise declare it as a false positive
(perhaps the user's computer was compromised). In fact, I've reached
out to a few people to see if they would be interested in aggregating
reports so we can collectively identify FPs more quickly.

So I guess I'm saying I have no preference to how it is done as long
as it solves the problem. I do think there is value in the
script-sample as that has been my biggest indicator that I can ignore
the report (and filter our similar reports). I like the stack idea,
but I haven't put much thought into it so I'll reserve any comments
for now :)

Late responses to other questions/points

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

Yes. We have implemented this functionality on multiple sites. CSP
reports are collected at a central endpoint for analytics and
correlation. And we found the Gecko reports to be valuable enough to
add this to applications. Webkit will send the reports everywhere. If
Gecko sent reports to something on the same origin, that would
probably suffice. But I still prefer the spec on this one.

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

I'm under the impression the consensus is that CSP shouldn't report on
activity from plugins. Being ignorant of the technical hurdles, would
that mitigate this issue? Of the script-samples I am seeing, I can
easily identify them as browser plugins.

On Tue, Dec 18, 2012 at 4:44 PM, Mike West <mkwst@google.com> wrote:
> Based on the discussion here and on today's call, I think there's
> rough agreement that source/line number pairs aren't particularly
> dangerous, and that they're certainly useful to developers. I've taken
> a first pass at adding them to the 1.1 spec as a strawman:
> https://dvcs.w3.org/hg/content-security-policy/rev/e0270baace3d
> Feedback is really quite welcome, especially from developers
> implementing CSP and fielding tons of violation reports. :)
>
> I'd like to add some sort of stack trace as well, but haven't written
> it up yet as I'd like some more feedback on the potential risk. As I
> mentioned on the call, I don't _think_ a trace would provide any
> exploitable information, but it's certainly more detailed than a line
> number, and deserves a bit more discussion.
>
> I remain skeptical about X-character samples, and I'm hopeful that we
> can find less direct ways of providing developers with helpful
> context.
>
> Thanks!
>
> -mike
> --
> 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 Tue, Dec 18, 2012 at 10:51 AM, Ian Melven <imelven@mozilla.com> wrote:
>>
>> 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 Wednesday, 19 December 2012 01:09:01 UTC