Re: Including the Javascript stack trace in the ContentSecurityPolicy report

2013/8/2 Henry Wong <henrywong@google.com>

> 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?
>
If the downsides of over-reporting (bigger network requests, admittedly not
that much for that use case) are manageable, I don't think there is.



> 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.
>
Agreed. The point I was trying to make is to have a higher-level mechanism
rather than stack traces, which depending on context (minified/inlined
code, etc.) may be hard or practically impossible to analyse. Not everyone
has Google's computational power and data analyst resources ;-)
I acknowledge that the particular solution I suggested is very error-prone
and isn't a good implementation, but I feel that the idea of a
developer-controlled higher-level mechanism should not be given up on just
yet (but I have to admit that I don't have a better idea yet).


> 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?
>
You already do:
function s(){
    try{
        throw new Error();
    }
    catch(e){
        return e.stack
    }
}
(you need to ignore the call to "s" as it's garbage, of course)

It's not standard, but works decently cross-browser. For standardization,
have a look on the ECMAScript side
http://wiki.ecmascript.org/doku.php?id=strawman:error_stack (it's not yet
on the standard track, but I feel it's only asking for people to push 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.
>
I wasn't aware of the event. That sounds like a good idea indeed!


> 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
>
I feel that it's an implementation limitation. Now that the stack trace is
available in window.onerror, I don't see why it wouldn't for this event.
In any case, the stack trace feels like only a small fraction of the
potential of the event. With the event, you can begin provide much *much*
more information about the context of the violation. You can send a portion
of a DOM tree for instance, why not the entire innerHTML if you want.


> alternatively being able to look at arguments.callee (or the equivalent in
> other browsers) would also be useful.
>
arguments.callee is standard, but throws in ES5 strict mode, I wouldn't
recommand using it.

David