Re: Content-Security-Policy: a "script-sample" report field is inadequate

Hi Sergey,

The main purpose of violation reports is to help developers deploy CSP by
identifying parts of their application which don't match the policy, so
that they can be refactored before the policy is switched into enforcing
mode. An attacker who finds an XSS could certainly inject a malicious
inline script and craft it so that a developer wouldn't learn about the
exploitation from the contents of the violation report; this is okay
because violation reports can't be reliably used to help discover the
exploitation of XSS anyway (despite, perhaps, some early claims to the
contrary).

Your point about violation reports not being helpful is shared by many
folks, but the snippets you pasted should actually be useful for debugging.
A developer can grep their codebase for such strings to see if any
legitimate inline scripts are being blocked. For external scripts, the
blocked-uri should generally help the developer pinpoint the offending
resource.

Re: reporting the HTML environment of a violating script, it seems like an
interesting idea -- can you explain what you mean in more detail?

Cheers,
-Artur


On Fri, Mar 3, 2017 at 7:39 AM, Виноградов Сергей <fdsc@yandex.ru> wrote:

> Hello
> I would like to give examples of how unhelpful are CSP violation reports (
> https://www.w3.org/TR/CSP2/ )
>
> A "script-sample" report field below
>
> 1. " ;(function() { \n     try { \n         /*..."
>
> 2. "/* See license.txt for terms of usage */..."
>
> 3.  A hacker can fill out the CSP report by spaces at the beginning. Need
> to ignore whitespaces and newlines.
> "(function(){                            ..."
>
> 4. AJAX scripts can load other scripts. So the web master need a field
> that which identify the cause of download script if the script loaded from
> other allowed the script
>
> 5. If the script appeared on the page, then web master need to give the
> html environment of this script ( to understand how was conducted an XSS
> attack).
>
>
>