Re: The HTTP Origin Header (draft-abarth-origin)

[oops, left off the list]

On Sat, Jan 24, 2009 at 3:00 AM, Adam Barth <w3c@adambarth.com> wrote:
> On Fri, Jan 23, 2009 at 11:08 PM, Robert Sayre <sayrer@gmail.com> wrote:
>> As proposed, the Origin header sounds certain to end up on those
>> proxies' blacklists.
>
> We've tried to respond to the privacy concerns raised by the Referer
> header in order to avoid falling into that trap.

The way to avoid falling into that trap is to avoid raising new
privacy concerns. I agree that the problems posed by Origin are not as
severe as the Referer header, in aggregate. But I don't think that is
a very interesting point to dwell on.

>
>> It can be difficult to police host names across an organization. There
>> is no reason to assume a string like "iphonekiller" (to use your
>> example) won't end up in the Origin header.
>
> Certainly this is conceivable, but much less likely that sensitive
> information in the path or query string.

In aggregate, sure.

> Moreover, because we do not
> send the Origin header for GET requests, these leaks require (in
> addition to a sensitive host name) a POST from an internal server to
> an external server.

Yes, I understand.

>
>> Secondly, it's easy to
>> generate POST requests with things that look like they should be GETs
>> (thanks to XHR).
>
> In all currently deployed browsers, XHR can only generate POST
> requests back to the same origin.  Surely we're not worried about
> leaking a host's name to itself.

Sorry, of course. Let's substitute a JS-triggered form post, or even
just a click on something that looks like link but it is an image form
button, and continue productive discussion.

>> Naively:
>>
>> schemes differ: 0
>> scheme same, hosts differ: 1
>> ...
>
> This scheme rules out the common use case of berkeley.facebook.com
> POSTing a request to www.facebook.com.

I did call my example out as naive and incomplete...

> You could imagine a more
> complex "URI proximity" description that supports this use case, but I
> haven't seen a good one.

Seems like it hasn't been needed previously.

>> I realize this approach is much more difficult to specify effectively.
>
> We could, perhaps, ask someone who operates a enterprise proxy that
> strips the Referer header to measure how often a POST request to an
> external URL has an internal host as a Referer.  This would allow us
> to evaluate how much information would be leaked by the Origin header.
>  I suspect these requests are quite rare, but I would welcome hard
> data on this point.

Information on the quantity would be nice to have, but I don't think a
new CSRF mitigation technique should introduce a privacy leak,
especially when it looks like there might be a way to avoid it that
you haven't explored.

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."



-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Received on Saturday, 24 January 2009 12:23:15 UTC