Risks of multiple HTTP standards
Pete Bentley <pete@mimir.com>
Tue, 03 Sep 1996 15:37:16 +0100
The Microsoft Network offers a free service allowing people to create
their own custom 'start' page at http://www.msn.com/ which may contain
personal information including the individual's address. All of this
information is encoded into a 'cookie' which is stored by the user's own
web browser and so in theory cannot be seen by other people. Or can it?
MSN uses Microsoft's own product, Microsoft Internet Information Server
1.0, as its web server and it tries to send a response which will ensure
that http://www.msn.com/ is not cached by any proxy servers (to prevent
people seeing each others information by mistake), but is cached by the
users web browser for a short time (for speed). It does this by sending
an HTTP/1.0 reply with Date and Expires headers which indicate that the
information is valid for half an hour and adds a "cache-control:
private" header to prevent any proxy servers from caching the
information. However, cache-control is a header from the draft HTTP/1.1
specification which is not interpreted by many HTTP/1.0 proxy servers in
use today (verified by myself with the CERN and Squid proxies) and so is
ignored. The remaining headers indicate to the proxy that it may cache
the page itself for half an hour. If the proxy then caches a page
containing a user's personal information then any other user accessing
http://www.msn.com/ via that proxy in the next half hour will receive
that page (and personal information). This scenario has indeed been
observed in practice with a busy web proxy run by a large ISP and a
detailed analysis has been sent to Microsoft for their attention.
The risk here seems to mostly be mixing HTTP standards and assuming that
HTTP/1.0 servers will understand some HTTP/1.1 headers. It raises issues
for both server coders and cache coders as the Net starts gradually
migrating to HTTP/1.1 at the same time as 'smart' web servers
(generating pages on the fly) want finer control over caching proxies.
Pete
[Aside: whilst making HTTP requests by telnetting to www.msn.com:80 (to
compare headers), I noticed that www.msn.com either restarts (connection
refused) or goes missing (routing loops between msn.net routers) quite
frequently. ]