Re: [websec] Indicating origin of OAuth credentials to combat login CSRF

["Manger, James H" <[e-mail]>]

>On Thu, Feb 24, 2011 at 4:08 PM, Manger, James H
><[e-mail]> wrote:
>> Q. Should an OAuth client app list the authorization server in the Origin
>> header of requests to resource servers?

Adam Barth replied:
> They are allowed to, but are not required to, by the Origin header
> specification.  Whether they should or not is a question for the OAuth
> working group to decide.

That is true, Adam, but I was hoping for a bit more advice from the group knowing most about "Origin" and cross-site requests about the need to indicate the server that dynamically provided an opaque value that the client is putting in the Authorization header of subsequent cross-origin requests.


Once specific question for websec is:
What semantics are associated with the *order* of origins in an "Origin" HTTP request header value?

The Origin spec implies (but doesn't explain) that there is some meaning to the order: a duplicate origin is omitted if it would be next to the same value (but included if there are intervening origins); and a site returning a redirect is appended to existing origins.

CORS seems to ignore the order of origins for non-preflight requests [http://www.w3.org/TR/cors/#resource-requests section 5.1 step 2].
CORS seems to imply a preflight request can only have a single origin in its "Origin" header [section 5.2 step 2]. That might not work well if OAuth says the authorization server shall be indicated in the "Origin" header as well.


Perhaps it would be better for the Origin header to be specified as a *set* of origins, not a list. That is, state that order doesn't matter (and no duplicates are allowed). Would that hinder any uses of Origin?


I suspect open redirectors are the problem. After a redirect, the origin of the original request no longer has any influence over the subsequent request so, theoretically, they should be dropped from the Origin header. In practise, that is only secure if trusted sites do not have open redirectors -- that might be too much to hope for.
It seems to me that the Origin spec is keeping the pre-redirect origins to cope with open redirectors, and implicitly hoping the order of origins can be used to ignore all but the last origin when necessary. Such an unstated hope interacts badly if OAuth adds an origin that isn't from a redirect.

--
James Manger