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

On Sat, Jan 24, 2009 at 8:08 AM, Robert Sayre wrote:
>
> As proposed, the Origin header sounds certain to end up on those
> proxies' blacklists.
>
> It can be difficult to police host names across an organization. There
> is no reason to assume a string like "iphonekiller" (to use your
> example) won't end up in the Origin header. Secondly, it's easy to
> generate POST requests with things that look like they should be GETs
> (thanks to XHR). I can definitely see blocking Origin at the firewall
> being appealing, since it doesn't require any analysis of internal
> host names or XHR usage.

What if the UA discard the Origin value (i.e. use "null" or some other
value) when crossing "zone" boundaries?
When an Intranet web page issues a request to an Internet resource,
then the UA SHOULD send "Origin: null" instead of "Origin:
http://<intranet-server>".

Could it work? (I suppose this could be done based on which range the
IP-address of the target resource belongs to, after DNS resolution;
but maybe DNS resolution doesn't always happen depending on the proxy
configuration –I don't know how this works)

> Thus I think it's a mistake to reveal the originating host name. This
> proposal would probably be much more likely to succeed if someone
> devised a way to describe the "URI proximity" of the origin URI to the
> target URI.

It would rule out communication from/to myproduct-tm.com to/from
mycompany.com, and it would make Origin much less appealing...
I believe there are legitimate needs for cross-site requests that are
not CSRF attacks (product-to-company; federated SSO; etc.)

-- 
Thomas Broyer

Received on Monday, 26 January 2009 10:01:40 UTC