Y
Y
Yan Aleksandrov2021-01-20 15:28:13
PHP
Yan Aleksandrov, 2021-01-20 15:28:13

Protection against uncontrolled creation of pictures?

I am using a library to generate images. Get parameters are appended to the regular url. Based on them, reduced copies of the original image are created. When accessed along the path:
https://путь/к/картинке.jpg?w=100&h=100a folder with the name 100*100 is created and an image with the corresponding size is generated there. When you re-access the picture is already given out of the folder.

How can you organize protection so that an attacker cannot create pictures by simply sending requests? In this case, it is desirable not to limit the user to preset sizes.

Answer the question

In order to leave comments, you need to log in

5 answer(s)
A
Alexander Talalaev, 2021-01-20
@neuotq

Google "Rate Limiting" for your framework, library, maybe at the web server level or whatever. And build the application logic in such a way that if you need to give not stats, then conditionally free, and if you generate, then there are restrictions. This is usually done per conditional device/user and/or separately per route/operation/function.
Well, for example, for the user 5 times per second, for the image generation route 100 times per second, if more than any limit, return code 429.

A
Armenian Radio, 2021-01-20
@gbg

Identify the user and impose a limit on the number of conversions.
For different categories - different degrees of severity of restrictions - for example, if you are logged in with a verified account on public services - there are few restrictions (10k requests per day), if it is a bunch of requests from an ip that is on the list of TOR output nodes - 1 request per day, then - captcha .

F
FanatPHP, 2021-01-20
@FanatPHP

A question from the series "a bad head does not give rest to the legs."
Another nonsense that comes from ridiculous fantasies (why on earth should the user set the size of the picture), and imaginary threats (there is no site, there are no pictures, the villains are not visible, but the fat must be hidden!) The implementation of which will make life difficult for normal users and in general will not stop the naughty fifth grader.
Answers too, toaster-style: "I'm not a doctor at all, I'm a plumber, but here's my expert opinion..."
In general, if this is a service for generating images in different sizes, then there is a stupid limit on the user, plus caching only standard sizes.
If this is a regular gallery, then forget about the moronic generation on the fly and do all the sizes immediately upon loading.

I
Ivan Brezhnev, 2021-01-20
@vanchelo

For example, in imgproxy, for protection, URL signing is used using HMAC https://docs.imgproxy.net/#/signing_the_url . You can do similar

V
Vladislav, 2021-01-20
@cr1gger

Why keep them?
Convert to base64 and give it to the user in this format.
And the browser itself will figure out what to do with it and display it normally.
You don't need to save them.
You only have the original image and then, when resizing, you give the user a base64 image, it can also be saved and substituted wherever you want.
It is possible even without base64 to tell the browser stupidly in the blob only in the headers:

header("Content-type: image/gif");
$img = file_get_contents('image.jpg');
echo $img;

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question