Re: Violation reports

Hey Adam,

I think many of your points below are valid, but I want to push back on
a few things.

(and apologies if I make less sense than normal... I'm under the
influence of cold medicine)

On 4/20/11 1:06 PM, Adam Barth wrote:
> It seems like there's a trade-off in the violation reports between how
> much information is contained in the report and which URIs are
> acceptable values for report-uri.
> 
> == Issues ==
> 
> Currently, the spec says to restrict the report-uri to "public suffix
> +1 DNS label."  Philosophically, I don't think we should be adding
> more things to the web platform that depend on the public suffix list.
>  That list is basically a hack we need to make cookies not be a
> complete security disaster.  Having more things use the that list is
> bad of the web.

We could also restrict the report-uri to the same origin (or host) as
the protected document.  This was how the directive was originally
proposed.  Public suffix +1 was added as a response to folks who wanted
to consolidate reports from multiple subdomains under one collector.

> Coming from the other direction, the violation reports current contain
> too much information.  For example, a malicious web site can use the
> blocked-uri field to learn where cross-origin redirects lead.  That's
> exploitable in a number of scenarios, which I can explain in more
> detail if you're unfamiliar with these attacks.

Yes, the attacker can learn about where cross-origin redirects lead, but
only if they get access to the report.  This is part of the motivation
behind locking down the report-uri.

> As another example, the SecurityViolation DOM event will contain the
> raw Cookie header field in the request-headers field.  If the Cookie
> header contains HttpOnly cookies, that will violation the security
> requirements of HttpOnly cookies.

Yes, this is true and I would propose to make a change to the spec that
removes HttpOnly cookies from the request-headers field of the
SecurityViolation event details.

> == Proposal ==
> 
> I recommend we simply violation reports to the point where we can send
> them to any URI.  Specifically, we should include:
> 
> 1) The document's URI.
> 2) The directive that was violated.
> 
> Notice that a bunch of other useful information (such as the
> User-Agent and cookies) will be included in the request automagically.

I definitely see the value of wanting a report format that carries no
risk of exposure, but I think this removes a great deal of the value of
the reports to the sites implementing CSP.

Twitter's recent experience [1] in implementing CSP is a great example
of what I'm talking about.  They learned through violation reports that
downstream ISPs were inserting JavaScript and modifying images in the
Twitter responses.  The blocked-uri field of the report was how they
discovered this information.  Without that information in the report, it
is unlikely that the developers alone could have tracked down the source
of those violations, since they would likely receive a different looking
response when they fetched those pages.

There is another way in which sending more information in the reports is
better: the ability to generate "signatures" for common violation
reports.  There may be non-malicious violations that commonly occur on
your site (think GreaseMonkey) and you might want to white list those
particular violations.  If Document URI and violated-directive are the
only fields in the report, it is very unlikely you could create
meaningful signatures.

I do think removing the request-headers field from the report sounds
reasonable, as the bulk of that information could be transmitted in the
report request "envelope".

> As a side note, instead of using JSON, we should just use regular
> application/x-www-form-urlencoded data.  JSON is very fashionable at
> the moment, but every server framework already knows how to deal with
> application/x-www-form-urlencoded data because that's what the <form>
> element generates.

I'm not crazy about this change, actually.  One of the things that is
nice about JSON is that the same JSON object sent in the report POST
body can be passed directly to the SecurityViolation event constructor
as the detail argument.

How would you construct the SecurityViolation event if you were using
application/x-www-form-urlencoded as the report format?

-Brandon

[1]
http://engineering.twitter.com/2011/03/improving-browser-security-with-csp.html

Received on Thursday, 21 April 2011 17:33:07 UTC