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
