- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 20 Apr 2011 13:06:51 -0700
- 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. Adam
Received on Wednesday, 20 April 2011 20:07:49 UTC