W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: [cors] Review

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 17 Jun 2009 19:11:11 +0200
To: "Tyler Close" <tyler.close@gmail.com>
Cc: "Mark Nottingham" <mnot@mnot.net>, public-webapps@w3.org
Message-ID: <op.uvoh0xbw64w2qv@anne-van-kesterens-macbook.local>
On Wed, 17 Jun 2009 16:35:13 +0200, Tyler Close <tyler.close@gmail.com>  
> On Wed, Jun 17, 2009 at 12:15 AM, Anne van Kesteren<annevk@opera.com>  
> wrote:
>> It also leaves sites vulnerable that do IP-based authentication.
> I assume you're talking about sites on the public Internet that rely
> solely on the client IP address for authentication, since we've
> already covered the firewall case.

I'm not too convinced that hoping the IT department deploys the new  
software correctly is going to work, to be honest. And while some  
heuristics might certainly help, that is not a solid solution.

> I think it's worth studying that
> scenario in more detail, because the details may save them. Responses
> lacking a cross-domain enabled header are still dropped by the
> browser, meaning we're only worried about side-effects from a request
> to a well-known URL.

Yes, either with methods other than HEAD/GET/POST/OPTIONS or headers other  
than the default set.

> Isn't it already possible to forge the IP address
> on a HTTP request to a web site, especially if you don't need to get
> the answer?

I don't know.

> It's also worth keeping in mind that both CORS and HTML
> also let a POST request through to the site,  so the site already
> needs some other way of authenticating these non-safe requests.

That could be as simple as using an HTTP header <form> cannot generate.  
Also, they might be using different methods.

Anne van Kesteren
Received on Wednesday, 17 June 2009 17:12:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC