Security Issue - Images and HTTP athentication

[mikelat]

I'm programming my own boards. I have realized in the past that an obvious problem with many board softwares is Image HTTP athentication. What that basically is:

Someone posts an image using the [img] tags on a forum. Once the image is posted, or even before, they make the directory that stores the image as "passworded". Some people can even make this so that it asks you for your forum login, appearing to be a part of the forum.

My first and more basic solution is that [img] tags and avatar linking is disabled for the new members group by default. You have to have 50 posts to use those options. It's simple, but effective, as deleting members who abuse this is simple and it is tough for them to redo this.

My second theory, is to parse the [img] tags so it is stored in the database, and every 3 minutes lets say (for page loads), it will "check" the image using the getimagesize function and trying to grab parameters of the image using that. If nothing is returned, it should disable the image. My conserns with this are:
1. If the getimagesize function fails, or the server fails, then it will disable it, thinking that the image is messed up or password protected. A possible solution is to have images be rechecked every few minutes or so whenever a page is loaded to see if its back to normal.
2. Another problem is bandwidth. From what I know, calling functions on remote images causes the server to use up bandwidth since it has to download the image.

My third theory, is to get the server to first check the image to see if its valid, then download it to the server and show it there. Although that may not be good for people wishing to conserve space, I could add a feature which removes these images when they haven't been viewed for 30 days.

Right now, Option #1 will be included indefinately. And options #2 and #3 may be included as extra options, of course the bandwidth or space issues will be displayed as drawbacks to using these options.

Any suggestions or comments on these techniques please, or better yet, another way then what I'm talking about here (an image checking technique that does not take up bandwidth preferably, but all suggestions welcome).

Thanks

[dgrinberg]

Personally, I prefer the method of saving the image on the forum's server.

However, how about saving the address of the image into a database and then calling the image through a PHP page so you can check the image before it gets to the browser.

For example the HTML image tag within the forum would look like

<img src='getimage.php?id=1234" />

Thus the browser would then call the getimage.php page instead of the images actual URL. You can then do any checking you want!!

[mikelat]

Thats option #2. 😉

[dgrinberg]

yeah, but my way you dont have to do the regular automated tests. You only test it when a broswer calls that image.

[mikelat]

There's a flaw in that though. Regular tests are actually better, because if you keep calling the image using php, php has to "grab" the image, thus taking up your bandwidth. The problem with that even more, is that php won't cache it or anything. It'll keep downloading the image.

What kinds of functions would you use for something like what you are thinking?

UPDATE: Wow, I think I just found what im looking for. This truly may innovate how we regard board software today. I'm gonna do some tests... more on this in a few hours.

[dgrinberg]

keep us in the loop!!!

[mikelat]

Something like this:

		$url = "http://www.urltoimage.com/whatever";

    $curl = curl_init();
    curl_setopt($curl, CURLOPT_URL, $url);
    curl_setopt ($curl, CURLOPT_NOBODY, TRUE);
    curl_setopt ($curl, CURLOPT_FAILONERROR, TRUE);
    curl_exec($curl);
    echo curl_getinfo($curl, CURLINFO_CONTENT_TYPE);
    curl_close($curl);

It actually works, and doesn't waste any bandwidth. It works pretty well, doesn't slow down really, and appears to be effective. I'm still playing around with it, but it looks promising. I already tested it with passworded images and it works.

The thing I'm going to try next, is spoofing headers to trick the script into running a php file or something. I don't know if it will work or not.

But already as it is this prevents annoying message boxes from coming up by using [img] tags. That as it is can bring me an edge in my board software of ridding all the little things that can make things easier for the admins.

My next consern is also how I'm going to call upon this. I already made a preg_match code that can parse links via http://xxxx.xxxxx.......

The next input I'd want from people is any security risks involved in having this being used in a GET. Seeing how databases can be slower with data such as this at times since images may be called upon in forum softwares very frequently, I'm debating that I should make it a direct like, like this: http://www.mysite.com/forum/stuff/getimage.php?url=http://www.yoursite.com/image.jpg.

Using urlencode, this is easy as pie. Got anymore feedback?

[Weedpacket]

Um, how is that any different from downloading the image? Hm. I guess all CURLOPT_NOBODY does is use a HEAD request instead of a GET request. Changing a line in Example 1 of the [man]fsockopen[/man] page would achieve this.

[mikelat]

The problem with image requests and things like that is that sometimes PHP has to "download" the file to run the function upon it. When it downloads the file, it takes up your bandwidth. Since these images are not cached by the users browsers, then it has to redownload everytime someone views an image.

In theory, lets just say that a random forum topic has just one 5kb image on it. It got 70 views. 350kb of the admin's bandwidth has just been wasted, and 5kb is a pretty small image size. They get bigger, and more views occur in most forums.

I know this happens on all the GD functions for accessing remote or local images. I haven't tried fsockopen but I assume its much of the same thing. The only function I saw that returned headers was one that only works for php5, but the code I showed above seems to work pretty well too.

I actually tested it and monitered a site's bandwidth meter. It did not go up (enough for the php execution but not for the image download), meaning it only grabbed the headers.

[Weedpacket]

So it does do a HEAD request, then (RFC2616, §9.4) as per Example 1 of [man]fsockopen[/man] with the obvious change.

[mikelat]

Hmm, that would work too I suppose. I have to compare them to see if theres any advantages or disadvantages between them.

EDIT: Hey, this is actually better. I can add some more security measures to prevent people from putting in certain types of headers. Thanks a bunch for the suggestions.

As you can see, I'm not really asking for help, I'm more asking for feedback. There should be a forum for PHP Theory somewhere around here.