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

Violation reports

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 20 Apr 2011 13:06:51 -0700
Message-ID: <BANLkTi=nBN=5=avVKqwa-ZYEYwCaSEUxcA@mail.gmail.com>
To: public-web-security@w3.org
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.

Received on Wednesday, 20 April 2011 20:07:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:26 UTC