- From: Tyler Close <tyler.close@gmail.com>
- Date: Wed, 17 Jun 2009 07:35:13 -0700
- 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 UTC