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: Wed, 5 Sep 2012 13:53:13 +1000
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: <F7064610-7F37-4F4A-A288-1B4A99681590@mnot.net>
To: Tero Kivinen <kivinen@iki.fi>
[ removing the IESG from the CC list]

Please see:
  https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#security.considerations

Cheers,


On 05/09/2012, at 12:11 PM, Mark Nottingham <mnot@mnot.net> wrote:

> Hi Tero,
> 
> CC:ing the HTTP mailing list.
> 
> These all seem reasonable. I'll work to update the Security Considerations and publish in -21, will ping you once that happens.
> 
> Thanks,
> 
> 
> On 04/09/2012, at 11:51 PM, Tero Kivinen <kivinen@iki.fi> wrote:
> 
>> I have reviewed this document as part of the security directorate's 
>> ongoing effort to review all IETF documents being processed by the 
>> IESG.  These comments were written primarily for the benefit of the 
>> security area directors.  Document editors and WG chairs should treat 
>> these comments just like any other last call comments.
>> 
>> This document is part 6 of the HTTP/1.1 and covers the caching in
>> http.
>> 
>> The security considerations section is quite short covering the case
>> that caches are attractive targets for attackers and that the fact
>> that cache can reveal information long after the information has been
>> removed from the network.
>> 
>> 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.
>> 
>> - 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.
>> 
>> - 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.
>> 
>> There most likely are still other attacks which I did not list above.
>> 
>> Also as cookies are quite often used in various things like
>> authentication, session identifiers, language selection etc, I think
>> the section 3 should mention something about them, especially mention
>> that RFC6265 says they can be cached (this was suprise for me, I would
>> have expected cookies to be counted in the same category as
>> authorization fields i.e. fields thta disable caching).
>> 
>> I was also suprised not to find warning about the caching of the
>> cookies in the RFC6265, but perhaps we should add note here in
>> security considerations section saying that by default cookies are
>> cachable, so applications using them must make sure they are not
>> cached unless wanted so. It might not be able to reach its intended
>> users (the ones writing web applications), but at least it might
>> spread the information to some relevant parties.
>> 
>> In summary I think this document needs bit more work in security
>> considerations section.
>> -- 
>> kivinen@iki.fi
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 5 September 2012 03:53:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 5 September 2012 03:53:59 GMT