- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 3 Feb 2009 14:33:17 +1100
- To: Amit Klein <aksecurity@gmail.com>
- Cc: Adam Barth <w3c@adambarth.com>, "Roy T. Fielding" <fielding@gbiv.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, ietf-http-wg@w3.org
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 <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 >> >> -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 3 February 2009 03:34:00 UTC