Symphony.

I think, the JIT Image Manipulation can easily be used to attack a symphony hosting webserver, with a denial of service attack.

The user can decide which image size JIT should generate. Thus it is possible, to request arbitrarily many different sized images (not cached images) at once. This means that the server has to resize the image for every request, producing very high load. Also these images will be cached, leading to high disk usage.

I wrote a small program which starts 20 of those requests in parallel. The webserver I tested, was not able to respond to any further requests, while the program was running, in an appropriate time.

All in all I would suggest to limit the number of different sizes, JIT accepts. So implementing a whitelist of allowed image sizes should resolve this problem. If a whitelist is implemented, JIT could still be used, to put a high load on the webserver, but the attacker would run out of images quite soon.

Related discussion from a few months back: image cropping in S2

I like the idea of named configurations, or “recipes” where you specify the dimensions and filters to apply.

It’d be great to hear any thoughts you have about how this can be fixed or implemented over that the above forum thread. It’s a discussion that is worth jump starting.

Related discussion from a few months back: image cropping in S2

I like the idea of named configurations, or “recipes” where you specify the dimensions and filters to apply.

It’d be great to hear any thoughts you have about how this can be fixed or implemented over that the above forum thread. It’s a discussion that is worth jump starting.

I read through the thread and I definitely like the idea of having named configurations, that can be then invoked via an URL parameter. Though I see the compatibility issue, I would not suggest, to leave this as an option, because this would lead to, having a lot of Symphony installations insecure.

One could provide an option, which enables the “old” behavior. But this should not be the default, so that the user explicitly has to say “Yes, I know what I am doing”. But that would force the people to deal with this issue.

About the external image caching issue: I would suggest the following. To use external images the user has to create a configuration, as mentioned above. This configuration should include

• The website (whitelist) to download the images from
• The destination size of the images
• The time to cache an individual image (e.g. one day)
• The maximal file size
• The maximal image size (in pixel)

The image should be identified by URL and only be reloaded if the caching time is over. One could think about, making some of these option global, so that they don’t have to be entered more than once.

This should give quite good, although not perfect security.