starred/pictshare

Fork 0

mirror of https://github.com/HaschekSolutions/pictshare.git synced 2026-04-26 07:25:55 +03:00

[GH-ISSUE #143] [Q/discussion] DDOS possibility #114

New issue

Open

opened 2026-02-25 23:40:44 +03:00 by kerem · 6 comments

kerem commented

2026-02-25 23:40:44 +03:00

Owner

Originally created by @Aivean on GitHub (Jan 15, 2023).
Original GitHub issue: https://github.com/HaschekSolutions/pictshare/issues/143

Hi!

We're trying to adopt pictshare for our (relatively) small blog: https://github.com/spaceshelter

And I'm a bit concerned about the absence of constraints on the resize filters, especially for the video. Currently it seems fairly easy to DDOS the server by hosting large mp4 and requesting all possible sizes for it.

Am I missing something? Let's brainstorm the best way to address that.

Originally created by @Aivean on GitHub (Jan 15, 2023). Original GitHub issue: https://github.com/HaschekSolutions/pictshare/issues/143 Hi! We're trying to adopt pictshare for our (relatively) small blog: https://github.com/spaceshelter And I'm a bit concerned about the absence of constraints on the resize filters, especially for the video. Currently it seems fairly easy to DDOS the server by hosting large mp4 and requesting all possible sizes for it. Am I missing something? Let's brainstorm the best way to address that.

kerem commented

2026-02-25 23:40:44 +03:00

Author

Owner

@geek-at commented on GitHub (Jan 16, 2023):

Good topic! On the old pictshare before the rewrite I had two more configuration settings. One was for max resizes per image and one was a resize code that hat do be present in the URL for the resize to be successful.

I didn't implement them in the new version because it was hardly ever used and even the public instance on pictshare.net never had any real problems with ddos but I do share your concern.

I'm not sure if the "max resize" setting is enough because that could potentially limit yourself too because it would be a server wide rule and not just for cpu intensive things.

What do you think would be a good solution for the problem?

@geek-at commented on GitHub (Jan 16, 2023): Good topic! On the old pictshare before the rewrite I had two more configuration settings. One was for **max resizes** per image and one was a **resize code** that hat do be present in the URL for the resize to be successful. I didn't implement them in the new version because it was hardly ever used and even the public instance on pictshare.net never had any real problems with ddos but I do share your concern. I'm not sure if the "max resize" setting is enough because that could potentially limit yourself too because it would be a server wide rule and not just for cpu intensive things. What do you think would be a good solution for the problem?

kerem commented

2026-02-25 23:40:44 +03:00

Author

Owner

@Aivean commented on GitHub (Jan 16, 2023):

The first thing that comes to mind is a rate limiter of some kind.

A very basic rate limiter (max N requests per period) that doesn't require a DB or shared memory can be implemented via the append-only log of timestamps: for each stored videofile have a log of the timestamps of the resize attempts. When a new resize attempt is made, check the timestamp of the Nth last record in the log, if it's earlier than period, allow the resize, otherwise deny it.

An IP-based rate limiter for all heavy operations would be ideal, but it would be tricky to implement in a performant way without the shared memory.

As a simplest band-aid solution, a config that entirely disallows video (or any) resizes could also work for some security-sensitive applications.

@Aivean commented on GitHub (Jan 16, 2023): The first thing that comes to mind is a rate limiter of some kind. A very basic rate limiter (max N requests per period) that doesn't require a DB or shared memory can be implemented via the append-only log of timestamps: for each stored videofile have a log of the timestamps of the resize attempts. When a new resize attempt is made, check the timestamp of the Nth last record in the log, if it's earlier than `period`, allow the resize, otherwise deny it. An IP-based rate limiter for all heavy operations would be ideal, but it would be tricky to implement in a performant way without the shared memory. As a simplest band-aid solution, a config that entirely disallows video (or any) resizes could also work for some security-sensitive applications.

kerem commented

2026-02-25 23:40:44 +03:00

Author

Owner

@geek-at commented on GitHub (Jan 17, 2023):

Yes a setting for disabling resizes of videos will be coming, that makes sense for server admins.

I was also thinking about making a queue (probably with redis) that only resizes one video at a time so even though the queue can become big, it will never crash or ddos the server

@geek-at commented on GitHub (Jan 17, 2023): Yes a setting for disabling resizes of videos will be coming, that makes sense for server admins. I was also thinking about making a queue (probably with redis) that only resizes one video at a time so even though the queue can become big, it will never crash or ddos the server

kerem commented

2026-02-25 23:40:44 +03:00

Author

Owner

@Aivean commented on GitHub (Jan 17, 2023):

Queue is a good idea, however one concern is that malicious agent would be able to saturate the queue and delay/prevent legitimate resizes.

@Aivean commented on GitHub (Jan 17, 2023): Queue is a good idea, however one concern is that malicious agent would be able to saturate the queue and delay/prevent legitimate resizes.

kerem commented

2026-02-25 23:40:45 +03:00

Author

Owner

@geek-at commented on GitHub (Jan 17, 2023):

good point! maybe per video a queue limit of 3 or so per hour per IP? but a distrubuted attack would render that useless

@geek-at commented on GitHub (Jan 17, 2023): good point! maybe per video a queue limit of 3 or so per hour per IP? but a distrubuted attack would render that useless

kerem commented

2026-02-25 23:40:45 +03:00

Author

Owner

@Aivean commented on GitHub (Jan 17, 2023):

Well, there are two somewhat separate issues:

service DOS (load from resizing interfering with the serving or other server functions).
Can be addressed by putting constraints on the resize work.
resizing DOS (i.e. malicious party denying resizing to other users).

Ideally, these would be addressed separately, e.g.:

resizing load could be limited by the isolated, resource-bounded workers with the constraints on parallelism
DOS can be mitigated by having IP-based and global rate-limiters, and/or using cloud-based DDoS protection in front of pictshare instance

With the current API (resizing happens anonymously on demand) I'm not sure if ideal solution is feasible. For example, if both uploading and resizing were tied to some sort of account (e.g. by an auth token), it would be possible to just add the restrictions per account.

But for the current design, the safest solution (which only really addresses the first problem) would be a global resize rate limit, together with the queue to flatten the peak load.

@Aivean commented on GitHub (Jan 17, 2023): Well, there are two somewhat separate issues: 1. service DOS (load from resizing interfering with the serving or other server functions). Can be addressed by putting constraints on the resize work. 2. resizing DOS (i.e. malicious party denying resizing to other users). Ideally, these would be addressed separately, e.g.: * resizing load could be limited by the isolated, resource-bounded workers with the constraints on parallelism * DOS can be mitigated by having IP-based and global rate-limiters, and/or using cloud-based DDoS protection in front of pictshare instance With the current API (resizing happens anonymously on demand) I'm not sure if ideal solution is feasible. For example, if both uploading and resizing were tied to some sort of account (e.g. by an auth token), it would be possible to just add the restrictions per account. But for the current design, the safest solution (which only really addresses the first problem) would be a global resize rate limit, together with the queue to flatten the peak load.