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

Re: Violation reports

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 26 Apr 2011 13:17:54 -0700
Message-ID: <BANLkTi=AM9bz87qOEnKh5FOaRJsPDPEVcA@mail.gmail.com>
To: Brandon Sterne <bsterne@mozilla.com>
Cc: public-web-security@w3.org
On Tue, Apr 26, 2011 at 11:44 AM, Brandon Sterne <bsterne@mozilla.com> wrote:
> On 04/21/2011 11:15 AM, Adam Barth wrote:
>>> 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.
>> Locking down the report-uri doesn't really help.  Here's a specific
>> attack scenario.  Let's consider a fictional, simplified version of
>> OAuth called XAuth.  (I haven't checked whether the real OAuth
>> protocol actually interacts badly with these reports.)
>> <snip>
>> 5) Alice's browser generates a violation report containing the URL
>> https://awesome-contacts.com/?XAuthToken=3987nocvn0q23n9ancv and sends
>> that report to the report-uri, which is
>> https://attacker.com/report.cgi.
>> 6) The attacker has learned the XAuth token for Alice's
>> mail.example.com contact list.
> Thank you for the run-through on that particular attack.  You have
> convinced me that the current design for reporting allows the leaking of
> redirected URLs to attackers, which could potentially contain sensitive
> information.
> I would still _really_ like to be able to communicate this information
> to the server, to the extent possible, to enable the Twitter use case I
> described in my last mail.  Let's see if we can find a middle way if
> possible.
> What if we sent the blocked-uri in the report if there is no cross-site
> redirect involved in the violation, and in the case there is such a
> redirect, we send the origin only?  We could also send a hash of the
> URL, as you suggested, though that does make things significantly harder
> to debug for server operators.

How about we send the full blocked-uri if it's same origin with
report-uri but send only the origin of blocked-uri if it's a different

>>>> 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?
>> IMHO, we should just get rid of the SecurityViolation event.  I was
>> hoping that we could use that instead of the report-uri, but you and
>> others have convinced me that sending an HTTP request with the report
>> is worthwhile.
> I am happy to remove the DOM event if that's what we want, though I'm
> still hesitant to switch the format from JSON to form-urlencoded.  JSON
> seems more than fashionable (there being a stable RFC for years) and is
> trivially parsable in every major server framework.  I do understand
> that form-urlencoded is already a format in use, but does that really
> necessitate this change?  Do other list members have an opinion here?

Surely form-urlencoding is more widely implemented by HTTP servers
than JSON.  Every HTTP server made in the past decade and a half
understands form-urlencoding.  Moreover, they'll continue to
understand it if/when JSON goes out of fashion (e.g., assuming
<form> and form elements are here to stay).

Received on Tuesday, 26 April 2011 20:18:54 UTC

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