W3C home > Mailing lists > Public > public-web-security@w3.org > April 2011

Re: Violation reports

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 20 Apr 2011 14:36:57 -0700
Message-ID: <BANLkTi=R3PajqFEMntWc1bWRhTy+FFd3XA@mail.gmail.com>
To: public-web-security@w3.org
P.S., report-uri should be relative to the document's URI, right?  I
didn't see that in the spec, but it would make sense.


On Wed, Apr 20, 2011 at 1:06 PM, Adam Barth <w3c@adambarth.com> 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.
> 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.
> 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.
> == 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.
> 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.
> Adam
Received on Wednesday, 20 April 2011 21:37:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:18 UTC