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.

Adam


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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 April 2011 21:37:56 GMT