- From: Tyler Close <tyler.close@gmail.com>
- Date: Wed, 17 Jun 2009 10:45:54 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Mark Nottingham <mnot@mnot.net>, public-webapps@w3.org
On Wed, Jun 17, 2009 at 10:11 AM, Anne van Kesteren<annevk@opera.com> wrote: > On Wed, 17 Jun 2009 16:35:13 +0200, Tyler Close <tyler.close@gmail.com> > wrote: >> >> 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 believe the described heuristics provide complete coverage for resources behind my company's firewall. Is there a common firewall configuration you are concerned about? The proposed solution uses both heuristics and configuration, not relying solely on either for protection. If this technique can in practice provide adequate protection, it is a much better solution than CORS, which undermines HTTP and webarch in a number of ways (all discussed previously and again raised by mnot). >> 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. http://en.wikipedia.org/wiki/IP_address_spoofing >> 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. In which case they are already vulnerable to IP address spoofing. --Tyler -- "Waterken News: Capability security on the Web" http://waterken.sourceforge.net/recent.html
Received on Wednesday, 17 June 2009 17:46:26 UTC