On Tue, Jun 9, 2009 at 11:19 AM, Adam Barth<[email protected]> wrote: > On Tue, Jun 9, 2009 at 9:38 AM, Tyler Close<[email protected]> wrote: >> On Tue, Jun 9, 2009 at 9:29 AM, Adam Barth<[email protected]> wrote: >>> Isn't the whole >>> point of this feature to be able to distinguish guest and non-guest? >> >> So requests from XMLHttpRequest have an Origin header, and requests >> from GuestXMLHttpRequest don't. The server should treat requests >> coming from GuestXMLHttpRequest as bits arriving from an unknown >> client (ie: a "guest"), and so only authorize them based on >> information explicitly included in the request. > > Given an HTTP request, what algorithm should the server use to > determine whether the request was generated by GuestXMLHttpRequest?
That's not the question the server wants to answer. The question is: How should the server treat any cookies (or other browser added credentials) in the request. 1) There is an Origin header: Treat any user credentials as indicated by the CORS spec for XMLHttpRequest. 2) There is no Origin header: a) request from legacy browser: If there are credentials in the request, use these as indicated by whatever CSRF defense you are using. b) request from non-browser client: If there are credentials in the request, the client has direct knowledge of them. They did not come from the browser's ambient environment. c) request from GuestXMLHttpRequest: There are no credentials in the request. The sub-cases of 2) collapse into: Treat any credentials in the request as you do today, guarded by whatever CSRF defenses you use. >From the perspective of your Origin work, requests from GuestXMLHttpRequest are like requests from a non-browser client, and so don't have a reliable Origin header value. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
