Newbie question on the security of signing the url

[Tokenyet]

Hi, I'm recently changing from thumbor user to imgproxy. Here are some questions of signing the url.

1. Why is the method avoid denial-of-service attack?
2. Should I use signing when I need to let frontend decide the size?

[DarthSim]

Hey!

1. It's highly recommended to put your imgproxy behind a cache or CDN so it will process each URL only once. When you sign your URLs, you don't allow an attacker to change the URL and bypass your cache. Also, it doesn't allow an attacker to change your URL to request a random image with random parameters, even if you don't use a cache.
2. Signing the URLs on the front-end side is absolutely meaningless. Everything available to the browser available to an attacker. If you have a list of presets you're going to use, you can use a combination of IMGPROXY_ONLY_PRESETS + IMGPROXY_ALLOWED_SOURCES to somehow secure your imgproxy, but it's less secure than using signatures anyway.

[depoulo]

If everything available to the browser available to an attacker, why does https://imgproxy.net/ give the example of security through obscurity by "protecting" from DOS attacks through an unauthenticated JSON POST route?

"exploit"


for width in {100..400}; do wget $(curl -s 'https://imgproxy-api-checdllhqq-uc.a.run.app/url' -X POST -H 'Referer: https://imgproxy.net/' -H 'Origin: https://imgproxy.net' -H 'Content-Type: application/json; charset=utf-8' --data-raw '{"image_url":"https://www.nasa.gov/sites/default/files/thumbnails/image/pia22228.jpg","video":false,"width":'$width',"height":532,"dpr":1,"gravity":"ce","resizing_type":"fill","blur":0,"sharpen":0,"pixelate":0,"brightness":0,"contrast":1,"saturation":1,"watermark_opacity":0.5,"watermark_scale":0.2,"watermark_position":"soea"}' | jq -r .url); done


For the use case where you have a list of presets you're going to use, can you elaborate on how exactly using IMGPROXY_ONLY_PRESETS or something like (https://github.com/shinsenter/docker-imgproxy/blob/5b924de671f8178deb6eb9bd25c973cf20a4e44c/imgproxy.conf#L132-L142) (+ IMGPROXY_ALLOWED_SOURCES if external images are needed) is "less secure than using signatures anyway"?

[DarthSim]

Well, it looks like you've just confirmed my point :)

We had to make some compromises to make our demo editor. Also, our JSON API that crafts and signs the URLs has some limitations under the hood so an attacker can't use it to sign literally any URL.

For the use case where you have a list of presets you're going to use, can you elaborate on how exactly using IMGPROXY_ONLY_PRESETS or something like (https://github.com/shinsenter/docker-imgproxy/blob/5b924de671f8178deb6eb9bd25c973cf20a4e44c/imgproxy.conf#L132-L142) (+ IMGPROXY_ALLOWED_SOURCES if external images are needed) is "less secure than using signatures anyway"?

There're a few examples that may or may not be applied to your case:

1. You probably have different kinds of images on your site. For example, user avatars and goods photos. Those kinds of images have different sets of sizes that are used on your site: avatars are always pretty small but goods photos may be large. An attacker may use this to make your imgproxy server busy for some time. Since you never use goods-related presets for avatars, you have no cached results for such a combination. So an attacker can grab a list of avatars' URLs and spam your imgproxy with avatar URLs + goods presets.

2. IMGPROXY_ONLY_PRESETS still allows specifying the resulting image format with the extension. So like in the previous example, an attacker can use different extensions to bypass your cache. BTW, it's a good feature idea to make some configs to prevent this.

3. A signature may serve as a privacy measure. For example, when you don't want every user to see every image. However, there's a tendency to obfuscate attachment filenames nowadays, so this may not be the case.

What I mean to say is that the signature is the ONLY thing that prevents an attacker from modifying your imgproxy URLs or crafting new ones. However, it's always up to you what to treat as vulnerability and what compromises to make.

[depoulo]

Thanks for the heads up, that was very helpful!

[yob-yob]

I know this is an old thread but I would like to ask what are some recommended Reverse Proxy Caching Layer that I could use for imgproxy?

[jburgyan]

Hello,
I see this is an old question, but the issue still stands.
If I need to sign every url on the backend, then the whole imgproxy implementation is kind of pointless.
The main advantage of using imgproxy is that frontend can decide the requested size based on screen size and resolution. If I have to make a connection to the backend for every single image just to generate a signed url then it makes everything slow (I have to make 2 connections instead of 1 to get the image).
Also if I use presets, it limits the frontend to use a predefined set of sizes, and hinders the advantage what imgproxy gives in avoiding to have to write complicated srcset generators.
Maybe a websocket connection could be used to get the signed urls fast from the backend, but websockets are not really reliable.
So probably the only real solution would be to build the DDOS protection in imgproxy itself (I know I can use cloudflare, but it either works or not, especially on the free plan).

[DarthSim]

Hey @jburgyan!

I don't really see a reason to argue here. Security measures are a matter of consideration and it's always a compromise. The more security measures you apply, the less flexibility you have. We provide some ways to secure your installations of imgproxy yet their usage is completely up to you.

As I said earlier, frontend is an insecure environment: everything you can do on frontend, everyone can do. So if you allow your frontend to generate imgproxy URLs, then anyone can generate URLs for your imgproxy installation and use it for their needs. URL signature is the only way to completely prevent usage of your imgproxy by third parties. Yet there are some configs like IMGPROXY_ALLOWED_SOURCES, IMGPROXY_BASE_URL, and IMGPROXY_ONLY_PRESETS that can help you to configure less strict secure installation.