[21100] in bugtraq
Re: The Dangers of Allowing Users to Post Images
daemon@ATHENA.MIT.EDU (peterw@usa.net)
Tue Jun 19 15:43:00 2001
Date: Tue, 19 Jun 2001 01:51:15 -0400
From: peterw@usa.net
Message-Id: <200106190551.BAA21459@rcn.com>
Content-Disposition: inline
Content-Transfer-Encoding: binary
MIME-Version: 1.0
To: Henrik Nordstrom <hno@hem.passagen.se>
Reply-To: peterw@usa.net
Cc: bugtraq@securityfocus.com, Tim Nowaczyk <zimage@upl.cs.wisc.edu>
In-Reply-To: <3B2BF7FF.2DA8F4D7@hem.passagen.se>
Content-Type: text/plain; charset=us-ascii
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.[0] 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?
-Peter
[0] 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.
