- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 14 Jan 2009 16:14:05 -0800
- To: Bil Corry <bil@corry.biz>
- Cc: Adrian Bateman <adrianba@microsoft.com>, Anne van Kesteren <annevk@opera.com>, Jonas Sicking <jonas@sicking.cc>, "public-webapps@w3.org" <public-webapps@w3.org>
On Jan 14, 2009, at 3:45 PM, Bil Corry wrote: > > Adrian Bateman wrote on 1/14/2009 3:18 PM: >> I actually don't think that the generic name is a problem as long >> as the >> CSRF solution uses a different name for a different meaning. The >> value really >> is an Origin and could potentially be used for more than just >> participation >> in the Access Control negotiation. It could still be meaningful in >> other >> scenarios in future which would otherwise now have to define a new >> header with >> the same meaning. > > I'm thinking out loud here, making sure I have the distinction > between the two correct: > > With Access Control, "Origin" represents the initial request, which > survives through a redirect. So as Adrian points out, it really is > an "Origin." > > With CSRF mitigation, "Origin" represents the immediately-preceding > request, which for obvious reasons does not survive through a > redirect. > > > That's why I liked the idea of just including the chain of requests > within Origin, you can then easily find the one you want. But since > that isn't on the table, I'm attracted to renaming the CSRF Origin > to something like "Request-Origin". Whatever name is chosen, it > then has to be added to the XHR spec as a header that can not > modified/created via XHR. Given this behavior, it sounds to me like the Access Control related header is more deserving of the term "Origin", since it represents the true origin of the request. I am not sure what the other header could be called to make the difference clear. Perhaps "Redirect-Origin"? Why does the CSRF defense header need to change on redirect? Regards, Maciej
Received on Thursday, 15 January 2009 00:14:50 UTC