W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Secdir review of draft-ietf-httpbis-p6-cache-20

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 18 Sep 2012 13:19:16 -0700
Cc: secdir@ietf.org, draft-ietf-httpbis-p6-cache.all@tools.ietf.org, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-Id: <5968E08E-1A55-440E-9A3C-1477A5832C50@mnot.net>
To: Tero Kivinen <kivinen@iki.fi>

On 18/09/2012, at 1:53 AM, Tero Kivinen <kivinen@iki.fi> wrote:

> Mark Nottingham writes:
>> Please see:
>>  https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#security.considerations
>> On 05/09/2012, at 12:11 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>> On 04/09/2012, at 11:51 PM, Tero Kivinen <kivinen@iki.fi> wrote:
>>>> I think the security considerations section should list other attacks
>>>> too. Things that comes to my mind:
>>>> - Cache poisoning attacks, i.e. attacker who can control the
>>>> www-server for a moment could pre-load cache with stuff that will
>>>> stay there for long time (as long as the cache control attributes
>>>> say). This includes negative result (404) caching.
> The current text for this seems to be ok (from the work in progress
> draft):
> 	Implementation flaws might allow attackers to insert content
> 	into a cache ("cache poisoning"), leading to compromise of
> 	clients that trust that content. Because of their nature,
> 	these attacks are difficult to mitigate.
>>>> - Cache caching stuff that was not supposed to be cached, like
>>>> authentication credentials in forms of cookies (the RFC6265 - "HTTP
>>>> State Management Mechanism" says that the presense of the cookies
>>>> does not preclude HTTP caches from storing and reusing a response).
>>>> This can be problem unless all applications using cookies actually
>>>> make sure that they set all pages as non-cacheable.
> Same for this:
> 	Likewise, implementation flaws (as well as misunderstanding of
> 	cache operation) might lead to caching of sensitive
> 	information (e.g., authentication credentials) that is thought
> 	to be private, exposing it to unauthorised parties.
> 	Note that the Set-Cookie response header [RFC6265] does not
> 	inhibit caching; a cacheable response with a Set-Cookie header
> 	can be (and often is) used to satisfy subsequent requests to
> 	caches. Servers who wish to control caching of these responses
> 	are encouraged to emit appropriate Cache-Control response
> 	headers.
>>>> - Cache might leak out information to other users of the cache who
>>>> fetched the page in the first time. This leaking can happen in
>>>> multiple ways (for example cookies, etc). Actually just timing can
>>>> tell that someone has already fetched the page to the cache, which
>>>> in some cases might be enough to leak information out.
> This was not added to security considerations at all. Was this
> intentional, or just left out by accident? Was there something unclear
> about this attack? 

I didn't see how it was materially different than the previous one (unintentional caching of sensitive information). Could you explain how it is?


Mark Nottingham
Received on Tuesday, 18 September 2012 20:19:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:06 UTC