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

Re: [cors] Review

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 17 Jun 2009 23:45:47 +0000 (UTC)
To: Tyler Close <tyler.close@gmail.com>
Cc: Anne van Kesteren <annevk@opera.com>, Mark Nottingham <mnot@mnot.net>, public-webapps@w3.org
Message-ID: <Pine.LNX.4.62.0906172333360.16244@hixie.dreamhostps.com>
On Wed, 17 Jun 2009, Tyler Close wrote:
> >
> > What you describe here seems to differ from what you described 
> > previously. I don't feel comfortable talking about our internal 
> > services, though, so I'd rather not elaborate.
> 
> We're just doing an existence test here. We don't need to know any 
> particulars. It'd be a shame to undermine webarch in an attempt to 
> preserve security that doesn't actually exist. We should make sure CORS 
> is not being unduly conservative.

When we're talking about security, I don't think being unduly conservative 
is a bad thing at all.


> It sounds like you might be changing your answer to: No, we don't have 
> such resources. Are you?

You asked two questions. I'm pretty sure we have services that match your 
original description. I haven't checked if we have specific services that 
match the second description, though it wouldn't surprise me. I don't want 
to elaborate.


> >> Is there any way a browser could tell a request is being sent to a 
> >> server behind your firewall, and not a server on the open Internet?
> >
> > No.
> 
> Does Google IT centrally configure any of your browser settings, so that 
> it could add this information to the browser?

I've never worked for a company that didn't give me root on my 
network-attached machines and let me configure them however I wanted.


> > This seems to fail for cases that aren't even Intranet cases. Consider 
> > for instance a publicly accessible SOAP service that does 
> > authentication on an IP address basis only, and relies on checking the 
> > Content-Type header to make sure forms can't submit to it.
> 
> This service is already vulnerable to IP address spoofing.

Unless there is some new attack I'm not familiar with, TCP (and thus HTPT) 
is not practically vulnerable to IP spoofing.


> 2009/6/17 Adam Barth <adam@adambarth.com>:
> > 2009/6/17 Anne van Kesteren <annevk@opera.com>:
> >> On Wed, 17 Jun 2009 16:35:13 +0200, Tyler Close <tyler.close@gmail.com> wrote:
> >>> 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.
> >
> > I'd classify this as moderately difficult. It's not something I can do 
> > for $5, but given a few hundred dollars, I can probably do it. Recall 
> > that sending an HTTP request requires a full TCP handshake, so its not 
> > as easy as SYN flooding.

That's news to me. As far as I can tell short of a man-in-the-middle 
attack it would take a phenomenal combination of a brute-force attack on 
the sequence numbers and a simultaneous DOS of the spoofee's network 
connection.

In practice these systems exist, and IP spoofing HTTP traffic is, as Adam 
put it, at least "moderately difficult". What you describe would change it 
from "moderately difficult" to "trivial".


> And also:
> 
> http://en.wikipedia.org/wiki/IP_address_spoofing

That page explicitly lists TCP as a protocol that isn't vulnerable.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 17 June 2009 23:46:19 GMT

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