Re: Violation reports

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.

>>> 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?

Cheers,
Brandon

Received on Tuesday, 26 April 2011 18:44:23 UTC