Re: Including the Javascript stack trace in the ContentSecurityPolicy report

Hi,

Thanks for the feedback. I have to admit that my experience is largely
skewed towards the technologies and projects I use at Google, so it's great
to hear other people's perspectives. I agree that a stack trace is often
useless, but it's also often extremely valuable; with our error handlers
(eg: window.onerror) we typically skew heavily in the direction of over
reporting rather than under reporting. Is there a particular reason not to
include the stack trace other than that it might not always be relevant?

Some further comments below:

On Fri, Aug 2, 2013 at 2:33 PM, David Bruant <bruant.d@gmail.com> wrote:

> Hi,
>
> I'd like to distinguish 2 cases: production and development.
> In development, I believe that changing the platform would be a mistake
> and that external tools like Casper.js [1] should be preferred (assuming
> they report CSP violations [2])
> Production is a different story as you can't embed tooling in your users
> browsers. Since I consider developmeent dealt with with tooling, let's only
> talk about production.
>
> 2013/8/2 Henry Wong <henrywong@google.com>
>
>> I'd like to propose that CSP reports include the Javascript stack trace
>> that resulted in loading the forbidden resource (similar to window.onerror).
>>
>> In many large web applications (eg: Google+) it's almost impossible to
>> figure out why a report was sent.
>>
> I imagine that in many large web applications, the JS is minified or even
> optimized with things like inlining (through e.g. the Google Closure
> Compiler) so I wonder how accurate and relevant the stack trace can be.
> Also, with promises [3] and async programming rising up, I wonder how
> relevant a stack trace can be. I know that in Node.js, a stack trace is
> rarely a relevant piece of information to debug (we joke on a regular basis
> with a friend on that topic).
>
> The document uri is typically just "http://plus.google.com" which doesn't
>> really give us enough context to know what the user was doing. For example,
>> if an XSS spreads via users' chat status then a stack trace that pointed to
>> the status message code would be much more useful than something that just
>> said there was a report sent from somewhere on the page.
>>
> But I understand that you need some context for the violation. An
> alternative idea to sending the stack trace could be adding a method like
> "navigator.setCSPViolationContext(context)" (I don't know where CSP-related
> methods are, but you get the idea).
> If a violation is detected, the latest context value is sent along the
> report (you can test that the right context is passed in developement mode
> with [1][2] ;-) ).
>
>
My main concern with this type of instrumentation is that it tends to be a
bit brittle, especially in large development teams where not everyone is as
knowledgable or careful as they could be. For example if an engineer
forgets to set the context (or if the code throws an exception and breaks
abnormally) then the context reported will be based on whatever previous
code happened to have been run.

If you're wary of including the stack trace in the report by default then
would it be possible to at least provide programmatic access to it? For
example, the spec currently describes an experimental feature for
SecurityPolicyViolationEvents<https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#script-interfaces--experimental>
-
these are DOM events that get fired when a CSP report is created. An
application could listen for these events and do its own custom reporting
including adding a stack trace. Unfortunately, the current implementation
of the event in Chrome does not provide access to the stack trace as far as
I can tell. Having the stack trace be included in the event would be great,
alternatively being able to look at arguments.callee (or the equivalent in
other browsers) would also be useful.

Henry



For the use case you described, you can set the context "chat" when dealing
> with the chat-related code and that comes along with your report. I feel
> that this form of user-created context will yield much better results than
> a stack trace, because it is at a higher-level of abstraction and doesn't
> care about the subtleties of a native definition of "resultded in" Boris
> mentioned.
>
> David
>
> [1] http://casperjs.org/
> [2] https://github.com/n1k0/casperjs/issues/494
> [3] http://dom.spec.whatwg.org/#promises
>