Re: The HTTP Origin Header (draft-abarth-origin)

On 23/01/2009, at 10:07 AM, Roy T. Fielding wrote:
>
> 1) CSRF is not a security issue for the Web.  A well-designed Web
> service should be capable of receiving requests directed by any host,
> by design, with appropriate authentication where needed.  If browsers
> create a security issue because they allow scripts to automatically
> direct requests with stored security credentials onto third-party
> sites, without any user intervention/configuration, then the obvious
> fix is within the browser.

Personally, I tend to agree; the number of problems caused by  
scripting are voluminous, and I think we'd do well to question its  
boundaries.

However, AIUI Origin isn't about exposing credentials, directly. The  
Referer header would be just as adequate for this purpose (assuring  
that the originating content is from an allowed host), except that the  
authors feel that Referer is stripped by proxies and user-agents in an  
attempt to improve privacy / limit exposure of sensitive data in URIs.

I don't think this argument is valid. The number of proxies that do  
this is very small. Those that exist will come under pressure to  
change their behaviour when their users notice that Web applications  
that rely upon this feature break behind those proxies.

In other words, just as the authors are satisfied having a staged  
deployment where some browsers on the Web support cross-site requests  
using their mechanism, while some still do not, I see no reason why it  
isn't just as acceptable to accept that some proxies will support it,  
and some will not; over time, more will.

Of course, *some* users have more direct control over what browser  
they use than whether a proxy is interposed, but not all do.


> 2) It doesn't prevent CSRF attacks because it doesn't prevent the
> Origin header field from being spoofed.  It therefore only improves
> a very small situation: a new browser that has implemented this new
> header *and* allows cross-site scripted requests *and* prevents any
> manipulation of the request header fields *and* is still stupid
> enough to include stored credentials in the cross-site request.
> It does nothing for existing browsers and actively interferes with
> existing non-browser user agents.

I think they're relying on existing browsers not allowing cross-site  
requests at all programmatically, and not having the ability to  
manipulate headers using other means (e.g.,   script src, etc.).

You make a good point about non-browser user agents. Origin  
effectively creates a new (and very primitive, as you note)  
authentication protocol for requests to what some would call  
"services," unless the server decides to also allow requests that omit  
the Origin header altogether. If they do that, however, it seems like  
a non-programmatic, non-Origin-creating browser would leave a hole...


> 3) It requires servers to maintain a table of "compliant" user
> agents in order to distinguish spoofed or dropped origin fields,
> which is known to be harmful to the introduction of new clients
> and results in all clients using copycat user-agents fields,
> thereby defeating the purpose of the table.

I understand the drop scenario (see above), but I don't see how it can  
be spoofed by a browser cross-site, provided that Origin is  
implemented with appropriate restrictions in new browsers (which may  
be a big ask, given the history of browser implementation...).


> 4) Even if such a feature becomes necessary, it can be far
> easier accomplished by changing the operational behavior of
> browsers such that they always send Referer and simply reduce
> the value of that field (similar to that specified for Origin)
> in those cases where it is currently not set at all.  No change
> would then be needed to HTTP and existing agents that already
> send Referer for these cases would already comply.

I don't agree. Unless it's very well-specified and implemented, this  
will have the effect of dumbing down Referer, reducing its utility for  
other purposes.

Cheers,

--
Mark Nottingham     http://www.mnot.net/

Received on Friday, 23 January 2009 00:20:50 UTC