- From: Amit Klein <aksecurity@gmail.com>
- Date: Sat, 31 Jan 2009 20:04:50 +0200
- 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 UTC