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

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

From: Amit Klein <aksecurity@gmail.com>
Date: Sat, 31 Jan 2009 20:04:50 +0200
Message-ID: <26162adb0901311004l2f9c8b18g35eabcf253e28418@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Mark Nottingham <mnot@mnot.net>, Bjoern Hoehrmann <derhoermi@gmx.net>, ietf-http-wg@w3.org

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 <w3c@adambarth.com> wrote:
>
> On Fri, Jan 30, 2009 at 3:16 PM, Roy T. Fielding <fielding@gbiv.com> 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
>
>
Received on Saturday, 31 January 2009 18:05:26 GMT

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