- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 5 Sep 2012 13:53:13 +1000
- To: Tero Kivinen <kivinen@iki.fi>
- Cc: secdir@ietf.org, draft-ietf-httpbis-p6-cache.all@tools.ietf.org, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
[ 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 UTC