Re: BBCode [IMG] [/IMG] Tag Vulnerability

[Christopher Kunz <chrislist () de-punkt de>]

Tony Stahler wrote:
> If you wanted to use the script to check it, yet not have to retrieve
> the image every time you could have your server download the image
> during the post request (assuming it was a reasonable size..) ... check
> it, and then have the link be local from that point onward.

That's not feasible for a number of reasons, some of which are pretty
straightforward:

a) Storage size and memory consumption - if you're maintaining a fairly large
forum or community, and we're talking something along the lines of 10,000
threads with around a million postings or such, you are looking at a fairly
large number of inline images, signature images and avatars - that doesn't scale
terribly well. To add insult to injury, getimagesize(), as all image-related
functions, consumes a lot of memory.

b) Traffic and load considerations: same as above - added to the traffic for
your forum, you have the traffic accrued by the images, and that can be a HUGE
factor. I'm hosting a gallery for my own pictures, and hotlinking traffic from
highly-frequented forums is a substancial factor in the 15 GB of transfer I have
each month. For each image, you need to either have a PHP wrapper that fopens
and streams it, or stream it directly to the user. In either case, a web server
child is gonna be busy with that.

c) Legal matters. I don't know how paranoid local governments are, but here in
Germany, you're bound to get a whole bunch of problems by hosting illegal
content on your web servers. Especially everything connected to the 3rd Reich
gives you instant attention by all the wrong people. That is not a claim - I
actually KNOW people who had URL grabbers to publish pictures posted on IRC to a
web-based gallery - and got litigated for spreading unconstitutional material.

To wrap it up: You don't want to host your users' images on your own server.

> You'd probably be better off just deciding which image file types you
> consider safe for users... i.e. you probably don't want to allow
> flash... and only allow images with those extensions.  Making sure
> images are safe isn't really you're responsibility, it's the
> responsibility of the image standard, and the browser displaying the
> information.  

Err... did you read the original posting? Extension-based filtering is not a
good idea (mkdir blah.jpg), and even checking the MIME type upon the initial
posting is not secure:

<?php
if ($_SERVER['REMOTE_ADDR'] == gethostbyname($victim_forum)) {
        // stream an actual JPEG
        // forum will think your image is genuine
} else {
        // CSRF-a-plenty here.
}
?>

This can even be accomplished without any PHP - you can have mod_rewrite
redirect based on any parameter from the environment, including remote host or
address.

Claiming that the image standard should be responsible for an image's contents
is kinda weird, too - since the principle of image-based CSRF attacks is that
the attacking file is NOT an image and doesn't even pretend to be.

The browser is maybe a good point to start thinking. Since all of these attacks
are (at some point) based on 30X redirects, if browsers wouldn't follow those
the attack would become impossible. But what else would break?

I have invested a lot of thinking, but can't come up with any sensible idea to
prevent such image-based CSRF attacks. As soon as you allow remote images in
your software, you are in the doghouse, at least AFAICT.

Just my 2 cents, other opinions (and solutions!) welcome.

--ck