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

From: Mark Nottingham <[email-masked]>
Date: Tue, 3 Feb 2009 14:33:17 +1100

Hmm. The difficulty here is that this is really specific to how HTTP  
is used; from HTTP's standpoint, there isn't any granularity in terms  
of what a "client" is; i.e., there's no delineation between browser  
code and downloaded code.

That said, I don't see why we couldn't flag Referer as having this  
issue in a note, and/or Security Considerations.

On 01/02/2009, at 5:04 AM, Amit Klein wrote:

> Historically it was possible to set some/all HTTP request headers via
> client side scripting (this was demonstrated with Flash several times,
> e.g. http://www.securityfocus.com/archive/1/441014). Referer was thus
> spoofed, rendering Referer-based defense methods useless. Obviously
> this was/is an implementation bug, but perhaps one that could be
> avoided had the HTTP standard mandated an explicit list of
> disallowed-to-set-from-client-side headers. Would it thus be possible
> to address such issue with the current proposal?
>
> On Sat, Jan 31, 2009 at 1:19 AM, Adam Barth <[email-masked]> wrote:
>>
>> On Fri, Jan 30, 2009 at 3:16 PM, Roy T. Fielding  
>> <[email-masked]> wrote:
>>> I was thinking something like
>>>
>>>  Referer: data:hidden
>>>  Referer: about:bookmarks
>>>  Referer: https:
>>>
>>> and others where appropriate.
>>
>> There is some value in having a catch-all "OMG, I can't figure it  
>> out"
>> value.  Keep in mind that you want to have a branch somewhere deep in
>> the bowels of the HTTP stack that enforces this requirement, and that
>> code might not have enough context to figure out that this was the
>> user clicking on a bookmark.
>>
>> Adam
>>
>>

--
Mark Nottingham     http://www.mnot.net/