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

Re: [cors] Review

From: Tyler Close <tyler.close@gmail.com>
Date: Wed, 17 Jun 2009 07:35:13 -0700
Message-ID: <5691356f0906170735j6fa22fa9qc6a44385050e694e@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: Mark Nottingham <mnot@mnot.net>, public-webapps@w3.org
On Wed, Jun 17, 2009 at 12:15 AM, Anne van Kesteren<annevk@opera.com> wrote:
> On Wed, 17 Jun 2009 07:41:42 +0200, Tyler Close <tyler.close@gmail.com> wrote:
>> One solution is:
>>
>> 1. Don't add any client credentials to requests.
>> 2. Allow the script to use whatever HTTP method, headers and request
>> entity it wants, restricting use of some headers, such as Referer.
>>
>> This leaves resources relying solely on a firewall for authentication
>> vulnerable.
>
> 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 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. 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? 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.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html
Received on Wednesday, 17 June 2009 14:35:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT