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.