Re: Line numbers in Content Security Policy reports

In reviewing the implementation of this feature in WebKit [1], one
issue that came up is that this feature might leak information about
cross-origin scripts (e.g., their URLs).  One approach is to use the
same mitigation use use for window.onerror: include this information
for same-origin scripts and for scripts loaded with CORS.

Adam

[1] https://bugs.webkit.org/show_bug.cgi?id=105374


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 Saturday, 5 January 2013 21:21:33 UTC