0

One of the key security mechanisms for application software is input validation, which can protect the integrity of the system and thwart common injection and denial of service attacks.

Most of the internet can agree that prepared statements can validate against SQLi, and sanitization libraries (that are not vulnerable themselves) paired with output encoding can mitigate XSS. However, I found that recommendations for validation of file uploads are often deprecated and/or ambiguous.

To provide a context for our system:

  • It runs on IIS 10 (Windows Server 2016), which hosts a .NET application.
  • The application has an endpoint that is contacting an external service, from which it receives images.

For protective controls, we have mutually-authenticated HTTPS (based on a hardened configuration of TLS 1.2) and we have a whitelist of allowed IP addresses for our endpoint to contact (redundant with certificate checking, but we are aiming for defense-in-depth). Now, when it comes to the file upload, we are currently examining the following validations:

  • Whitelist of magic numbers - Currently we have magic number checking, and we are unsure how easy it is to spoof this value. Would adding validations for extensions or MIME add anything to this step?
  • File size and file name length checking - we limit the size of this data to avoid DoS.
  • Regardless of the original image name, it is renamed following internal system convention - in theory to avoid injection attacks through the name.
  • The image is scanned by an antivirus prior to any further manipulation.

Is our validation chain missing important steps? Since we're working with images, I've heard talk about reencoding them to remove attacks, but I haven't been able to find any details on this subject.

Improve this question
1
  • I cannot find any information what the files are used for after they get uploaded. To get some idea why this information is important: for example if the uploads just get deleted (unlikely) then sanitizing is not really needed. If the images instead get processed later by some buggy application running as root within a sensitive environment then lots of sanitizing should better be done - and the kind of sanitizing might depend on what this application exactly expects.
    – Steffen Ullrich
    Commented Dec 19, 2018 at 10:24

1 Answer 1

Reset to default
1

I think you're not missing something, and in my opinion there is no way to testify that an image is 100% clean unless you analyze it by hand, I'd say adding MIME validation (in both client and server side) is a step to do before validating against magic number, this will eliminate some script kiddies :)

Now if you really want to reduce your attack surface, you can first reencode the image into a simple/poor/trivial format, in a sandboxed environment with a minimum privilege and no access to unnecessary syscalls. Once you get the reencoded file, you can re-reencode it to a more common format (png/jpeg..) At this stage you can trust the input since it comes from your system, and use stream or maybe memorystream to convert your image (try and catch everything !)

Improve this answer
1
  • if the images aren't large or are infrequent, you could always dynamically load them in a sandbox, attach to the newly created window and screenshot the image. if you don't need high fidelity, this would ensure that regardless of what's in the sent-file, the screen-shot file will only be the image.
    – thepip3r
    Commented Dec 19, 2018 at 16:07

You must log in to answer this question.

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