0

I' m building a REST API with Django and Django Rest Framework. I allow users to upload images and videos using different subclasses of ModelSerializer. When a file is received, the server saves it to a temporary file on the disk (with Django TemporaryFileUploadHandler and only after the default validation) to perform custom validation. I need to validate the resolution of images / videos and the duration of videos. If validation succeeds the file is uploaded to AWS S3. My question is, if the file contains malicious code, could validating the file directly on the server be dangerous (I’ m hosted on a EC2 instance running Amazon Linux 2)? I will now report the parts of the code that I am particularly concerned about.

To validate the resolution of an image I use Django util get_image_dimensions:

width, height = get_image_dimensions(image)

To validate the resolution and the duration of a video I use moviepy (I know there are more efficient options like ffprobe, but I prefer that way for other reasons):

from moviepy.editor import VideoFileClip
video_file_clip = VideoFileClip(video.file.temporary_file_path())
video_duration = video_file_clip.duration
width, height = video_file_clip.size

I wrote that code in the clean method of a model used to contains posts, before running it I validate the file extension with Django FileExtensionValidator (I know that the file extension is not a guarantee) and the file size by accessing file.size. Should I also validate something else at the Django level before using the above code? Thanks in advance.

1 Answer 1

1

Python is, in general, pretty secure against arbitrary code execution vulnerabilities in file parsers. The most likely problem you'd face would be if you were invoking an external program to parse or process the files, in which case there'd both be risk of command injection vulns (which may be mitigated by the temporary file names) and/or parser errors causing memory corruption. With pure python code, the most likely risk is that you'll mis-parse the file (think it claims one resolution or length, when a different codec might "see" a very different value).

One very simple test you can do, before even parsing the file data, is just checking its size. That isn't a perfect protection against some attacks (such as "decompression bombs") but it's impossible to spoof the compressed size, at least, as being smaller than it is.

If you wanted to be really paranoid, you'd create a sandbox environment (using a VM, or using the sandboxing features of the Linux kernel) and try loading the file within it using a conventional media player app. Then you could see what its length, resolution, etc. are in an environment where malicious code couldn't do anything (ideally, you'd want to extract the data from outside the sandbox, rather than trust anything within it to report accurately). That's almost certainly not needed, though, unless the consequences of uploading maliciously over-size media are really bad.

1
  • Thanks for your detailed answer. Commented Sep 7, 2021 at 6:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .