Re: Origin (was: Re: XHR LC Draft Feedback)

2008-06-23 Thread Adam Barth
On Mon, Jun 23, 2008 at 1:18 PM, Bjoern Hoehrmann <[EMAIL PROTECTED]> wrote: > * Adam Barth wrote: >>There are three cases: >> >>1) Origin header missing: This is a non-supporting browser. Fall >>back to existing CSRF defenses. >>2) Origin header has a trusted value: Accept the request. >>3) Or

Re: Origin (was: Re: XHR LC Draft Feedback)

2008-06-23 Thread Bjoern Hoehrmann
* Adam Barth wrote: >There are three cases: > >1) Origin header missing: This is a non-supporting browser. Fall >back to existing CSRF defenses. >2) Origin header has a trusted value: Accept the request. >3) Origin header has an untrusted value: Reject the request. Yes, and I am saying, if th

Re: Origin (was: Re: XHR LC Draft Feedback)

2008-06-22 Thread Adam Barth
On Sat, Jun 21, 2008 at 6:51 PM, Bjoern Hoehrmann <[EMAIL PROTECTED]> wrote: > The stated goal was to balance easy protection against session riding > attacks without compromising privacy too much. Allowing session riding > via some sites but not others is something that cannot be done securely >

Re: Origin (was: Re: XHR LC Draft Feedback)

2008-06-21 Thread Bjoern Hoehrmann
* Collin Jackson wrote: >The advantage of the Origin header is that it provides sites with >functionality that can't already be emulated with XMLHttpRequest: it >allows them to distinguish trusted (sub)domains from completely >untrusted domains. The stated goal was to balance easy protection agai

Re: Origin (was: Re: XHR LC Draft Feedback)

2008-06-21 Thread Collin Jackson
On Sat, Jun 21, 2008 at 2:57 PM, Bjoern Hoehrmann <[EMAIL PROTECTED]> wrote: > * Adam Barth wrote: >>We suggest that user agents attach an Origin header to POST requests. >>This balances the security benefits of easy CSRF protection with the >>privacy costs. If user agents attached this header, s

Re: Origin (was: Re: XHR LC Draft Feedback)

2008-06-21 Thread Bjoern Hoehrmann
* Adam Barth wrote: >We suggest that user agents attach an Origin header to POST requests. >This balances the security benefits of easy CSRF protection with the >privacy costs. If user agents attached this header, sites could >protect themselves from CSRF by (2) undertaking state-modify actions >