W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2009

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

From: Mark Nottingham <mnot@mnot.net>
Date: Sat, 31 Jan 2009 09:30:41 +1100
Cc: Bjoern Hoehrmann <derhoermi@gmx.net>, ietf-http-wg@w3.org
Message-Id: <B1E2CDD6-5904-49B0-A268-7356FBC94424@mnot.net>
To: Adam Barth <w3c@adambarth.com>


On 31/01/2009, at 4:56 AM, Adam Barth wrote:

> On Fri, Jan 30, 2009 at 12:23 AM, Mark Nottingham <mnot@mnot.net>  
> wrote:
>> On 25/01/2009, at 10:16 AM, Adam Barth wrote:
>>> 1) The attacker can force a user agent to suppress the Referer  
>>> header,
>>> mimicking a user behind a Referer-stripping proxy.
>>
>> Can you walk us through this attack, please? Or give a reference...
>
> As Thomas says, there are lots of ways to do this, mostly by design.
> Here is a list of the top of my head:
>
> 1) The attacker hosts his HTML page over HTTPS and mounts a CSRF
> attack against an HTTP URL.
> 2) The attacker hosts his HTML page over FTP.  Browsers don't send FTP
> URLs in the Referer header.
> 3) The attacker hosts his HTML page over GOPHER.  Browsers don't send
> GOPHER URLs in the Referer header
> 4) The attacker hosts his HTML in a DATA URL.  Browser don't send DATA
> URLs in the Referer header.
> 5) The attacker hosts his HTML in a frame whose URL is the empty  
> string.
>
> There are many more ways, but none of these are bugs.

OK, so can't we get incremental improvement by specifying what Referer  
should be in these situations, and having browsers implement that?


--
Mark Nottingham     http://www.mnot.net/
Received on Friday, 30 January 2009 22:31:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:01 GMT