mailing list archives
Re: The Dangers of Allowing Users to Post Images
From: peterw () usa net
Date: Tue, 19 Jun 2001 01:51:15 -0400
At Sun, 17 Jun 2001 02:21:19 +0200 , Henrik Nordstrom <hno () hem passagen se> wrote:
Regarding the discussion on Referer checks. These are quite weak and
won't necessarily gain you anything in terms of security. It is well
known that Referer can be forged, and to further add to this some
browsers preserve Referer when following redirects, allowing this kind
of attacks to bypass any Referer check if your users follows URL's
(direct or indirect via images) posted by other users or even your own
staff when linking to external sites.
Folks are missing the point on the Referer check that I suggested.
With a three-phase security model, the server checks
1) authentication info (cookies, HTTP Basic, SSL cert, etc.)
2) that the URL is correct, and required arguments are present
3) [in this case] that the Referer exists and looks correct
An attacker can trick the victim's browser into sending 1 + 2. Or the attacker himself can send 2 + 3. But the attacker
cannot get the victim to send 1 + 2 + 3, unless the application is poorly designed.
See the source code for acmemail (the /acmemail tree in CVS) for an example. Messages are only displayed with a URL
like /cgi-bin/acmemail.cgi. But interesting things (logging out, deleting messages, sending messages) are only offered
on pages with URLs like /cgi-bin/acmemail.cgi/control/. And interesting things are denied unless the client has a
Referer of /cgi-bin/acmemail.cgi/control/. So you send me an HTML message with a CSRF IMG tag. My browser displays that
in /cgi-bin/acmemail.cgi and requests something dangerous of /cgi-bin/acmemail.cgi/control/. But it sends a Referer of
/cgi-bin/acmemail.cgi because that's where I saw your image. So even though conditions 1) and 2) check out, condition
3) fails and the attack is blocked. Now, if you know of a way to embed an IMG tag that will convince my http client
to lie about the URL that IMG tag was on, I'd like to hear it.
But the fact that an attacker can deliberately send a request that maches conditions 2) and 3) doesn't bother me, as
that's not sufficient to do anything important. You can trick an acmemail user into askingthe system to list messages
in their inbox or something, but who cares about that?
 This all assumes you are intelligent about your configuration; the acmemail security is in-flux, and the default
settings may be changed before the official 2.2.3 release.