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

On Jan 22, 2009, at 5:47 PM, Adam Barth wrote:

> On Thu, Jan 22, 2009 at 4:41 PM, Roy T. Fielding  
> <fielding@gbiv.com> wrote:
>> I don't understand -- the only case that would be affected
>> is the one wherein no Referer is sent today.
>
> The problematic case is when the Referer header is suppressed by the
> network (e.g., proxies).  In this case, the Referer header is
> suppressed regardless of its value.  Choosing a different value will
> not help Web sites defend themselves against CSRF.

The feature of "defend themselves against CSRF by identifying
the referral page" is satisfied by "don't allow requests that
lack an appropriate Referer".  Your estimate that it would also
block some 3% of false negatives does not lessen its defense.
The 3% would get an error message in response.

Your claims are based on the assumption that those very same
3% proxies will forward the Origin header unchanged.  Your
assumption is wrong.  The proxies that remove request headers
today are the ones that remove all request headers and rewrite
each request on their own terms -- the main ones being the
content-translating proxies used by some wireless networks and
the firewall-translating proxies used by a few large corporations.
Both of those cases are just as likely to adapt their feature set
to unreachable services "protected" by Referer as they are to
unreachable services "protected" by Origin.

Furthermore, unlike Origin, Referer is in use today, would not
add extra bits on the wire, and doesn't require further standards
work (outside the browser implementation standards) to define.
A 3% initial failure rate is just noise compared to deploying an
entirely new header field.

....Roy

Received on Friday, 23 January 2009 02:29:42 UTC