Hello,
it seams that Cyrus httpd does not set the Cache-Control header
appropriate when serving private data. When operated behind a reverse
proxy with caching (like for example Apache httpd with mod_proxy), there
is a possibility that an unauthenticated anonymous client gets access to
private information. I can reproduce this issue by having one client
access the caldav URL with BASIC HTTP authentication. After this I use
another client and request the same caldav URL without providing BASIC
HTTP credentials. As long as the backend data did not change between the
requests (304 Not Modified), the second client gets the private data
without authentication from mod_proxy (which is unaware of the fact that
this is private data).
Therefore I think it would be required to set the Cache-Control header
for all httpd responses to "private".
As this is not an uncommon setup - having a reverse proxy doing the SSL
offloading and URL routing - there might be a lot of hosts affected.
What is the best way to address this issue?
Kind regards
Matthias
Oct 31 23:18:33 mail http[14179]: read_body(flags=0x10, framing=2)
Oct 31 23:18:35 mail http[14167]: read & parse request-line
Oct 31 23:18:35 mail http[14167]: read & parse headers
Oct 31 23:18:35 mail http[14167]: conn flags: 0 upgrade flags: 0 tls
req: 0
Oct 31 23:18:35 mail http[14167]: write_body(code = -1964266973,
flags.te = 0, len = 0)
Oct 31 23:18:35 mail http[14167]: simple_hdr(Date: Thu, 31 Oct 2019
22:18:35 GMT)
Oct 31 23:18:35 mail http[14167]: simple_hdr(Connection: Upgrade)
Oct 31 23:18:35 mail http[14167]: simple_hdr(Upgrade: h2c)
Oct 31 23:18:35 mail http[14167]: simple_hdr(Cache-Control: must-revalidate)
Oct 31 23:18:35 mail http[14167]: simple_hdr(Vary: Accept-Encoding)
Oct 31 23:18:35 mail http[14167]: simple_hdr(ETag:
"1569656021-1572492600-17592-1569921236-602")
Oct 31 23:18:35 mail http[14167]: simple_hdr(Last-Modified: Thu, 31 Oct
2019 03:30:00 GMT)
Oct 31 23:18:35 mail http[14167]: [10.0.3.2] as "mpeterma" with
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,
like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0"; "GET
/dav/calendars/user/mpeterma/ HTTP/1.1"
(if-none-match=W/"1569656021-1572492600-17592-1569921236-602") =>
"HTTP/1.1 304 Not Modified"
On 10/7/19 7:45 AM, Matthias Petermann wrote:
Hello,
since Cyrus is able to share calendars, I try to set up a CalDAV server
using Cyrus httpd behind an Apache reverse proxy (mod_proxy). During
this I made a security-related observation which makes me a bit
concerned. It seems to be about caching private data, probably more an
issue of my individual setup and not a bug in Cyrus. Anyway – I am a bit
clueless and would be happy to discuss this to find a mitigation.
...
Test setup / precondtions:
- Cyrus 3.0.11 server (imapd, httpd) freshly restarted
- Apache 2.4 with mod_proxy (ssl vhost, no explicit cache configuration,
only mod_socache_shmcb)
- Browser A with clean cache
- Browser B with clean cache
Test steps:
1) Request CalDAV URL from Browser A
- Expected: Browser presents HTTP Auth, delivers content after
successful login
- Observed: Browser presents HTTP Auth, delivers content after
successful login
- Result: PASS
2) Request same CalDAV URL from Browser B
- Expected: Browser presents HTTP Auth
- Observed: Browser delivers content without presenting HTTP Auth
- Result: FAIL
Test observations:
- The result of step 2) seems to differ depending of which Cyrus httpd
process is hit by the request
- The cache-control header delivered by Cyrus httpd seems to not contain
„private“ which seems to allow intermediate caches to cache private data
...
My first configuration of Apache did allow mod_proxy to reuse the
backend-connections to Cyrus httpd. After I added disablereuse=On (which
causes Apache to close the backend-connection immediately after
processing a single request), it seems to mitigate the observed issue.
How could this be possible? These two questions could help me to
investigate further on my system:
- When receiving a HTTP Request with an Etag included, when exactly does
Cyrus httpd decide whether to request HTTP Authentication? In case the
Etag is valid (content unchanged), will it return the 304 without
requesting a HTTP Auth?
- How do the Cyrus httpd workers handle HTTP Auth in general? In case of
re-using a worker by a permanent connection from a reverse proxy, does
it check Authentication on any request, or only at the very first?
I am happy about suggestions or pointers to best practises in regards of
using Cyrus httpd behind a reverse proxy.
Kind regards
Matthias
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
