Re: [http-state] Security considerations overview

[Adam Barth <[e-mail]>]

On Tue, Mar 2, 2010 at 4:04 PM, David Morris <[e-mail]> wrote:
> On Tue, 2 Mar 2010, Adam Barth wrote:
>> On Tue, Mar 2, 2010 at 3:27 PM, David Morris <[e-mail]> wrote:
>> > No. Network attacks that impact HTTPS in general should not be used
>> > to claim that cookies, by default, are not secure. Network infrastructure
>> > manipulation which would reveal totally HTTPS website cookie content would
>> > also expose everything else about the HTTP based application to intercept,
>> > manipulation, etc.
>>
>> We're not talking about vulnerabilities in HTTPS or TLS.  We're
>> talking about the default behavior of the cookie protocol itself,
>> which does not provide confidentiality from network attackers.
>>
>> > I still don't see the actual vulnerability, and haven't yet reviewed
>> > the backing details, but I think that makes me the typical reader of
>> > the summary. If what I read in the summary doesn't make sense, I'll
>> > probably ignore the details.
>>
>> The issue is quite simple:
>>
>> 1) In an HTTPS response, the example.com server responds with
>> "Set-Cookie: foo=bar".  By default (i.e., without the optional Secure
>> attribute), this cookie does not have the secure-only-flag set.
>> 2) The user agent makes a single HTTP request.
>
> That case was excluded by my earlier restriction to all HTTP.

Even if a web server operates exclusively over HTTPS, general purpose
user agents are willing to issue HTTP requests.

>> 3) The network attacker spoofs an HTTP response that contains an HTTP
>> redirect to http://example.com/.
>
> Only applies if there is an HTTP server on the same host. And it requires
> a vulnerable infrastructure at either end of the connection.

We're discussing a network attacker.  A network attacker can spoof an
HTTP response from a host even if that host is not operating an HTTP
server.  Likewise, a network attacker can intercept an HTTP request to
a host even if that host is not operating an HTTP server.

> This also suggests some issues with HTTP redirect which have not been
> discussed in my reading/listening. It potentially exposes more than
> cookies to the sniffer of traffic.

What issues with HTTP redirects do you mean?  That's how HTTP
redirects work according to the HTTP specification.

>> 4) The user agent follows the redirect and sends the cookie foo in the
>> clear, where it can be observed by the attacker.
>>
>> > Furthermore, I suspect these vulnerabilities depend on the specific
>> > User-Agent implemenation.
>>
>> No.  The vulnerability is in the design of the protocol.
>
> No. I can build special purpose useragents which will never have these
> vulnerabilities.

We're talking about the protocols as specified.  You can profile HTTP
and the cookie protocol to make them more secure, but that's not how
they work out-of-the-box.

>> > The executive summary needs to provide an accurate description of
>> > the issue. I'd try to suggest an alternate set of words, but I don't yet
>> > understand the basis of the claim.
>>
>> The issue is described in detail later in the section.
>>
>> > The generic summary statement proposed below applies equally to anything
>> > associated with HTTP. By default the content isn't secure. If that is what
>> > you mean, than say something like:
>> >   Cookies as a subset of the HTTP protocol share all of the security
>> >   vulnerabilities of HTTP and in some cases may excerbate the
>> >   issues because of the possible leakage of cookie content to
>> >   unintended servers...
>>
>> That summary is insufficiently harsh.  The cookie protocol has a
>> number of design errors that impair its security far more than the
>> rest of the HTTP protocol.
>
>    Cookies as a subset of the HTTP protocol share all of the
>    security vulnerabilities of HTTP and in some cases cookie
>    design flaws may excerbate the issues because of the
>    possible leakage of cookie content to unintended servers...
>
> makes it stronger? or since this is a summary, perhaps stop with
> "excerbate the issues"

I don't think we should be mealy mouthed here.  The protocol is not
well-designed for security.  We should be clear so that folks aren't
confused into creating vulnerable servers.

Adam