From dev-return-60310-apmail-httpd-dev-archive=httpd.apache.org@httpd.apache.org Mon Feb 11 12:59:16 2008 Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 10730 invoked from network); 11 Feb 2008 12:59:16 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Feb 2008 12:59:16 -0000 Received: (qmail 44704 invoked by uid 500); 11 Feb 2008 12:59:06 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 44656 invoked by uid 500); 11 Feb 2008 12:59:06 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 44645 invoked by uid 99); 11 Feb 2008 12:59:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Feb 2008 04:59:05 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [195.232.246.84] (HELO mo1.vodafone.com) (195.232.246.84) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Feb 2008 12:58:19 +0000 Received: from mi1.vodafone.com (mi1.vodafone.com [195.232.246.138]) by mo1.vodafone.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m1BCwepq027399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Feb 2008 13:58:40 +0100 Received: from avoexs04.internal.vodafone.com (avoexs04.dc-ratingen.de [145.230.4.198]) by mi1.vodafone.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id m1BCwdd9021304 for ; Mon, 11 Feb 2008 13:58:39 +0100 Received: from VF-MBX11.internal.vodafone.com ([145.230.5.20]) by avoexs04.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 11 Feb 2008 13:54:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: cache - cleaning up mod_memcache and making other caches their live easier Date: Mon, 11 Feb 2008 13:54:55 +0100 Message-ID: <99EA83DCDE961346AFA9B5EC33FEC08B464667@VF-MBX11.internal.vodafone.com> In-Reply-To: <77C1A5C0-76F0-4815-A30D-A4EAF393B8B6@webweaving.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: cache - cleaning up mod_memcache and making other caches their live easier Thread-Index: Achsp24ja4LrDT2nSXuDrLd9+cA+owAAmAvA References: <04F3FAAB-F309-4534-B7F4-906B23E3B174@webweaving.org> <47AF706C.200@apache.org> <778538F1-250F-42DF-864D-A4821DA6E0B6@webweaving.org> <99EA83DCDE961346AFA9B5EC33FEC08B464662@VF-MBX11.internal.vodafone.com> <77C1A5C0-76F0-4815-A30D-A4EAF393B8B6@webweaving.org> From: =?iso-8859-1?Q?Pl=FCm=2C_R=FCdiger=2C_VF-Group?= To: X-OriginalArrivalTime: 11 Feb 2008 12:54:58.0104 (UTC) FILETIME=[4E6E1B80:01C86CAD] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::080211135839-4F095BB0-064AF49A/0-0/0-0 X-Virus-Checked: Checked by ClamAV on apache.org =20 > -----Urspr=FCngliche Nachricht----- > Von: Dirk-Willem van Gulik =20 > Gesendet: Montag, 11. Februar 2008 13:12 > An: dev@httpd.apache.org > Betreff: Re: cache - cleaning up mod_memcache and making=20 > other caches their live easier >=20 >=20 > On Feb 11, 2008, at 12:58 PM, Pl=FCm, R=FCdiger, VF-Group wrote: >=20 > > The contents of the cache is not protected by any means. So I do not > > see a security issue here. Somemone who has access to one=20 > cache entity > > has access to all. >=20 > Agreed. But what I worry about is that you get some subtle=20 > interaction =20 > with some obscure header; which effectively is used by some site =20 > builder as implying certain access - or used, say, for ensuring that =20 > certain documents are only shown to, say, French people. >=20 > There is no doubt that this is 'wrong' on just about every level -- =20 > but given how careless some of the new web app frameworks are put to =20 I agree that some web app frameworks might be careless, but the cache is IMHO the wrong location to fix this kind of sloppyness. On the contrary I think we must make clear explicitly that nothing in the cache is = protected from access. Keep in mind that none of the access / authz restrictions = apply to cached content. No deny from / require directive will be applied to = cached content once it is in the cache. It is open to *anyone*. The only security issue we must take care of is to avoid cache = poisoning. This might be possible with the following kind of requests: GET / HTTP/1.0 User-Agent: enMozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; = rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 Accept-Language: GET / HTTP/1.0 User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv: = 1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 Accept-Language: en which may both have Vary: Accept-Language User-Agent in there response. But as we create the key of [old_key][header name][header value].... both requests result in = different cache keys (keys are hashes of the values below): /Accept-LanguageUser-AgentenMozilla/5.0 (Macintosh; U; Intel Mac OS X; = en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 /Accept-LanguageenUser-AgentMozilla/5.0 (Macintosh; U; Intel Mac OS X; = en-US; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4 So I see no danger for cache poisioning here. Regards R=FCdiger