Re: [cors] Review

On Wed, Jun 17, 2009 at 4:45 PM, Ian Hickson<ian@hixie.ch> wrote:
> 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.

So turn off your computer then. ;) "unduly" is always undue.

>> 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.

Huh. So, how should we proceed? Should we drop this proposal on the
hypothesis that there might exist resources that require the more
conservative approach taken by CORS? Regardless of the costs this
imposes?

>> >> 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.

That's fine, but presumably these companies also provide some setup
assistance to you. Does Google IT have any way to put configuration
settings in your browser? For example, do you install packages from a
Google provided repository? I've heard Google uses something called
Goobuntu, or some such. Do you install your own machines, or does
Google do that for you?

>> > 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".

Adam quantified "moderately difficult" at a few hundred dollars.
That's pretty cheap.

I think we should also look for more details here. These systems that
are using the client IP address for authentication, is the client
computer an end user computer with a browser installed on it?

>> And also:
>>
>> http://en.wikipedia.org/wiki/IP_address_spoofing
>
> That page explicitly lists TCP as a protocol that isn't vulnerable.

with caveats that seem important:

"""
Since the attacker normally can't see any reply packets, he has to
guess the sequence number in order to hijack the connection. The poor
implementation in many older operating systems and network devices,
however, means that TCP sequence numbers can be predicted.
"""

Let's not brush aside details that could be important to solving this problem.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Thursday, 18 June 2009 00:12:15 UTC