jawadi121 / smart-lencioni-image-resizer

Automatically exported from code.google.com/p/smart-lencioni-image-resizer
GNU General Public License v3.0
0 stars 0 forks source link

Security problem, attacker can drain server resources. #20

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Attacker selects a link of an image.

2. Attacker changes the set dimensions of the link so the script generates a 
new image instead of using cache.

Making a program that spam http links with random generated dimension numbers 
in the link can easily be done in any programming language.

3. Server runs out of resources/crashes/gets disabled by host etc!

What version of the product are you using? On what operating system?
2.0b3, Win7

Please provide any additional information below.

A simple solution could be to allow a number of maximum requests per day/hour 
or similar.

So if the script has been run 10 times in 1 day/hour. Then it will not use 
resizing/cropping etc any more and only use the Cached images. Having a 
variable so it can be set manually depending on what kind of site it is.

There's also an idea of using a security key in each request here:
http://shiftingpixel.com/2008/03/03/smart-image-resizer/#comment-1900

Also there might be another security issue which I do not know of but there's a 
script similar to yours I believe called phpThumb.

I found an exploit for it that makes it possible for an attacker to shell the 
website and I think that SLIR might have similar problem.

Is the script using any sanitizing? (I'm sorry I haven't read through your 
whole source)

Info on this particular exploit: http://secunia.com/advisories/39556

If SLIR doesn't have any sanitizing already then it's a good idea to implement 
it.

I hope you can add some security to prevent that simple DoS that would make 
your script priceless.

Thank you for developing and sharing!

Original issue reported on code.google.com by pew...@gmail.com on 11 Jun 2010 at 9:27

GoogleCodeExporter commented 9 years ago
I made a little attempt to resolve this my self. It is working BUT! It's not a 
very pretty solution. It pretty much writes to a txt file every time the script 
resizes an image as well as the timestamp. If it generated more then 10 images 
in 1 hour then it will exit the script. But it still allows cached images to 
display.

in slir.class.php around line 183 I added this:

                // Check the cache based on the request URI
        if (SLIR_USE_REQUEST_CACHE && $this->isRequestCached())
            $this->serveRequestCachedImage();
        else {
            $textFile = "num_of_requests.txt";      
            $fh = fopen($textFile, 'r');
            $lastTimestamp = fgets($fh);
            $numberofRequests = fgets($fh);
            if ($numberofRequests == "") $numberofRequests=0;
            if ($lastTimestamp == "") $lastTimestamp = time()."\n";
            fclose($fh);
            if ($lastTimestamp >= (time()-3600)) {
                $fh = fopen($textFile, 'w');
                $numberofRequests++;
                $stringData = $lastTimestamp.$numberofRequests;
                fwrite($fh, $stringData);
                fclose($fh);
                if ($numberofRequests >= 10) {
                    die ("To many attempts");
                }
            }
            else {
                $numberofRequests = 0;
                $lastTimestamp = time();
                $fh = fopen($textFile, 'w');
                $numberofRequests++;
                $stringData = $lastTimestamp."\n".$numberofRequests."bajs";
                fwrite($fh, $stringData);
                fclose($fh);
            }
        }

Original comment by pew...@gmail.com on 11 Jun 2010 at 11:55

GoogleCodeExporter commented 9 years ago
Surely the above solution would stop you from having >10 images on a page/site?

Original comment by jimeagle on 4 Aug 2011 at 10:24