File upload is one of those can’t-live-with-it, can’t-live-without-it items that makes information security so fraught with difficulty. On the one hand, it automates parts of doing business – especially B2C business – that would typically require a person to make a phone call, send an email, or even dust off their fax machine.
On the other hand, allowing customers, partners, or vendors to upload files directly to your application is pretty much a recipe for disaster. Here’s how attackers can take advantage:
Scenario 1: Zero Protection at All
Let’s say that you’re like an unfortunately large number of websites, and have chosen to put zero protections on your file upload portal. Unrestricted file upload is an immensely dangerous scenario — what are attackers going to do with this?
Mechanically, it’s pretty easy to build an upload form into a given website using just HTML for the frontend and PHP for the backend. When a user uploads a file through the HTML form, the PHP script will store it in a temporary location directly on the server alongside some accompanying metadata.
In this example, with no validation, no virus scanning, and no restrictions on filenames or file types, there is an infinite universe of possible attacks. The name of the file could be a malicious code string, the file itself could be a weaponized executable, and so on. Moreover, while there are some ways to reinforce this basic kind of upload portal, they’re pretty easy to circumvent.
Scenario 2: Basic Protection
Suppose you’re a doctor, and your website has a portal which accepts x-ray scans from various radiologists. You want to ensure that only radiologists, and not unauthorized individuals, have access to this portal, so you decide that people should only be able to upload images, such as JPEGs, to your portal. As a JPEG is not an executable file, this protection should make you marginally safer.
In technical language, this is known as MIME-type validation. MIME stands for “Multipurpose Internet Mail Extensions,” and a MIME-type is part of the metadata that gets sent to a server when a user tries to upload a file. In essence, the MIME-type indicates what a file is and what it’s supposed to be used for.
Unfortunately, nothing prevents an attacker from sending an executable file with its MIME-type rewritten to make it look like a JPEG. Similarly, administrators could try writing an upload portal so that it would only “.jpeg” file extensions. Getting around this would require a bit more work, but the possible solutions still boil down to “name your malicious PHP file as something like ‘shell.jpg.php’ until the whitelister gets confused.” It’s not a form of protection that would stand up to a determined attacker.
Scenario 3: Image Validation
If you’re really determined to code a secure file upload portal, one of the last best ways to validate that an image file upload is a real image is to manipulate it as though it were an image.
Just for example, you can use the server-side command “getimagesize()” to query the dimensions of an image that’s been uploaded. If the command returns a FALSE value, then what’s been uploaded isn’t an image at all – it’s probably a malicious executable.
This last gate would only deter a lazy hacker, however. Using a free image program, it’s possible to open an image file and edit its metadata to include malicious PHP code. As the image is a valid jpeg, it will pass validation, and the malicious code will execute as soon as it is accessed by a browser.It’s nearly impossible to validate anonymous image uploads using good coding practices alone. For best results, augment application access with security such as antivirus, which can be brought in line by Safe-T Software Defined Access. This makes it possible to monitor an uploaded file through its entire lifecycle, scanning files in a secure zone behind a hidden DMZ. These protections mitigate the typical techniques used to bypass validation – making it that much more likely that an attacker will move on to a softer target. For more information, request a free Safe-T demo today!