Re: [http-state] Seeking feedback on Security Considerations

[Adam Barth <[e-mail]>]

On Sat, Feb 13, 2010 at 2:48 AM, Yngve N. Pettersen (Developer Opera
Software ASA) <[e-mail]> wrote:
> On Sat, 13 Feb 2010 09:01:08 +0100, Adam Barth <[e-mail]> wrote:
>> 7.5.  Weak Integrity
>>
>>   Cookies do not provide integrity guarantees for sibling domains (and
>>   their subdomains).  For example, consider foo.example.com and
>>   bar.example.com.  The foo.example.com server can set a cookie with a
>>   Domain attribute of ".example.com", and the user agent will include
>>   that cookie in HTTP requests to bar.example.com.
>
> A bar.example.com can also overwrite a ".example.com" cookie set by
> foo.example.com. Maybe that should be mentioned?

Done.

> Another possible issues that maybe should be mentioned is that in shared
> hosting environments where multiple independent services are hosted in the
> same domain or on the same server it is possible for a malicious service to
> interfere with other services by setting cookies for domains and paths that
> will get them sent to other services.

Indeed.  I've added this paragraph:

[[
        <t>Even though the cookie protocol supports the Path attribute, the
        Path attribute does not provide any integrity protection because the
        user agent with accept an arbitrary Path attribute in a Set-Cookie
        header. For example, an HTTP response to a request for
        http://example.com/foo/bar can set a cookie with a Path attribute of
        "/qux". Consequently, servers SHOULD NOT both run mutually distrusting
        services on different paths of the same host and use cookies store
        security sensitive information.</t>
]]

> Should the fact that clients also support cookies through HTML meta tags and
> the Javascript document.cookie API be mentioned? The latter could be a
> concern when including external Javascripts directly into a HTML document.

Hum...  Maybe we should add a new section about interactions with non-HTTP APIs?

Adam