On Wed, Jun 17, 2009 at 12:15 AM, Anne van Kesteren<[email protected]> wrote: > On Wed, 17 Jun 2009 07:41:42 +0200, Tyler Close <[email protected]> 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
