W3C home > Mailing lists > Public > public-webappsec@w3.org > August 2013

Re: Including the Javascript stack trace in the ContentSecurityPolicy report

From: David Bruant <bruant.d@gmail.com>
Date: Fri, 2 Aug 2013 14:33:33 +0200
Message-ID: <CAHbscB2j078wuW8GdS+eVcdNiyZsA8FU5mQcU_e2R7Hc-UKftA@mail.gmail.com>
To: Henry Wong <henrywong@google.com>
Cc: public-webappsec@w3.org, Mike West <mkwst@google.com>, Adam Barth <abarth@google.com>, Jad Boutros <jad@google.com>

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] ;-) ).

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


[1] http://casperjs.org/
[2] https://github.com/n1k0/casperjs/issues/494
[3] http://dom.spec.whatwg.org/#promises
Received on Friday, 2 August 2013 12:34:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:34 UTC