Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Validations are run after versions created #1320
I'm currently attempting to mitigate a DoS attack against sites with CarrierWave enabled. An attacker can upload an image with an arbitrarily large width and height in the image header (and no correspondingly large image data), which causes tools like imageMagick to consume significant resources on the server.
This is pretty not great.
I've added a validator to my User model, which checks the dimensions of the image and adds errors to it if dimensions are greater than some arbitrary threshold (e.g. 1000x1000).
The validations are not called before image manipulation happens (server still chokes).
I can use a callback on the uploader (e.g. before :cache) to raise an exception, but this is an inelegant solution (I'd much prefer to run validations before mogrifications, saving the creation of the versions, and showing the user a nice clean error message)
Is there some other solution?
As an addendum: https://github.com/DarthSim/carrierwave-bombshelter fixes the underlying issue (e.g. memory exhaustion if the image file header claims it's, say, 64250x64250 pixels -- looks like we're not using ImageMagick's --limit option anywhere?)
carrierwave-bombshell looks reasonable if you're concerned about this issue. Not all Rails apps are inherently vulnerable as stated above (not all process images, not all use ImageMagick).
This is a system/ImageMagick issue, not a CarrierWave issue. CarrierWave itself has no code that interacts with ImageMagick. The bombshelter gem chooses to address the problem using CarrierWave, but that doesn't make it CarrierWave's problem.
Addressing it with environment variables (
As a solution, I can propose a special callback for validations, so we'll be able to do the following:
after :validate, :check_video_length def check_video_length(new_file) return if videl_length_is_ok? fail CarrierWave::IntegrityError, "Video is too long" end
Standard validations could be wrapped into this callback.