[615] in WWW Security List Archive
HTTP "Referer" field considered harmful
daemon@ATHENA.MIT.EDU (Prentiss Riddle)
Mon Apr 24 16:19:08 1995
From: riddle@is.rice.edu (Prentiss Riddle)
To: www-security@rutgers.edu
Date: Mon, 24 Apr 1995 08:28:52 -0500 (CDT)
Errors-To: owner-www-security@ns2.rutgers.edu
FYI:
There is an interesting security problem in the HTTP protocol, which
comes to light in CERT security Advisory S-95-12:
http://www.cs.ruu.nl/cert-uu/satan-advisories/S-95-12.txt
CERT advisories are always teasingly vague on a few points, but my
interpretation of this one is as follows:
HTTP permits the client to tell the server what URL the user was
previously browsing, for the purpose of data collection about hypertext
references and user behavior in following them. This information is
passed in the HTTP "Referer" field (see
http://www.w3.org/hypertext/WWW/Protocols/HTTP/HTRQ_Headers.html#z14).
It can be accessed by CGI programs in the HTTP_REFERER variable, and
patches are available to allow NCSA httpd to log this information as
well (see http://www-iwi.unisg.ch/~dlincke/httpd-ext.html).
Unfortunately, some URLs contain secret information. The CERT advisory
concerns one example: SATAN, the Unix network security tool, can be
accessed by system administrators using HTTP and attempts to restrict
access by embedding a session password in its URLs. If a user jumps
elsewhere from within a SATAN session, the SATAN URL may be revealed to
the other HTTP server. (I suppose that this means that some browsers
do not implement the Referer feature in a strict sense of "this is the
URL that pointed to your server" but rather "this is the URL that the
user was looking at before jumping to your server". The CERT advisory
is unclear ont his point.)
SATAN 1.1.1, by the way, apparently "solves" this problem by warning
the user when it detects a browser that implement the Referer feature.
As a webmeister, I like the idea behind the Referer field and plan to
make more use of it to determine what sites are pointing at mine.
Perhaps the real problem lies in assuming that URLs will remain secret
and therefore assuming that they are an appropriate mechanism for
passing secrets or performing session authentication.
-- Prentiss Riddle ("aprendiz de todo, maestro de nada") riddle@rice.edu
-- Systems Programmer and RiceInfo Administrator, Rice University
-- 2002-A Guadalupe St. #285, Austin, TX 78705 / 512-323-0708
-- Opinions expressed are not necessarily those of my employer.