Any files on your website can be dangerous if they didn't come from trusted sources. They may not be what you expected. A maliciously uploaded file can do a variety of harm:
- Extracting confidential information from the server
- Altering pages to deceive the user
- Putting dangerous scripts on the website
- Downloading malware to users' machines
- Making the site unusable
Any website that accepts user uploads has to be very careful about them. Even if it just accepts profile pictures, there's a risk. If an intruder can get unrestricted files onto the server and then run them or make users download them, that's a website security concern. Such sites have what is called a local file inclusion vulnerability.
The risks of file uploads
Some sites have good reasons for letting users upload files. When users are active participants in an online community, they like to make pictures of themselves available, along with other personal files. Letting them create image galleries or custom text can be a great way to engage them. But if they can upload files that aren't checked, that opens up a serious vulnerability. It's necessary to limit uploads to safe ones and control the way they can be used.
There's a related vulnerability that doesn't involve user uploads. Sometimes it's classified as a local file inclusion vulnerability. It turns up when users can get the system to invoke an arbitrary file path. For example, if an attacker can get a page to include /etc/passwd, then it gets information which makes it easier to crack user passwords. That's called a path traversal vulnerability, and for this discussion, we'll treat it as a separate issue. This article focuses on files provided by the user or surreptitiously inserted into the Web directory.
File names in the URL
If a user can access the file by URL after uploading it, it's likely there's a vulnerability. There are two ways this might happen.
If the file goes to a location under the Web directory without changing the name, it's accessible by URL. Suppose, for example, all files go to the uploads directory. If the file is called sample.jpg, then it's URL will be something like http[:]//www[.]example[.]com/uploads[.]sample[.]jpg. That may be harmless enough. But what if it's sample.php? Then the user can run code on the server just by invoking the file's URL.
The other way to invoke a file turns up if the Web application accepts a file name as a URL parameter or form field. It might be something like this: http[:]//www[.]example[.]com/DisplayFile[.]php?file=sample[.]jpg. That's fine as long as the file is really a harmless JPEG, but if it's something sneaky, the situation could turn dangerous.
When is an image file really a hostile file? One situation arises when the file is designed to exploit a browser bug. This danger turns up when users don't update their browsers, and the version they have contains a bug which a deliberately defective file can exploit. In some cases, a suitably crafted file can run arbitrary code on the client's machine. It can install malware or crash the computer.
The image might not be an image at all. If the server trusts the file extension and doesn't do any other checks, then a file with a JPG extension might actually be HTML, PHP code, or anything else. That could let dangerous files run on the server or the browser.
The most popular server-side programming language for websites is PHP. Unfortunately, the language provides a lot of ways to run data as PHP code. If an attacker can upload a PHP file and the server has any security defects, getting the file to run on the server might be quite possible.
If the uploader can access the file by a URL, it's absurdly easy.
- Step 1: Upload a PHP file.
- Step 2: Invoke the PHP file by its URL (e.g., http[:]//example.com/uploads/evil[.]php). It will immediately run on the server, with all the privileges of the account that runs the Web application.
Another trick is to get an existing PHP file to include it, perhaps by giving it a parameter that points at the file. The result is similar; the malicious code runs on the server, with few restrictions on what it can do.
Closing off the vulnerability
The surest way to avoid the local file inclusion vulnerability is to allow only trusted files on your site. The large majority of websites don't need files from strangers.
If your site's purpose requires letting people upload files, there are ways to make it safer. Uploads should come only from registered users.
Everything uploaded should go through an automated verification process. It should really be the file type that its extension claims. If a .jpg file doesn't have a JPEG header, the server should reject it out of hand. Anti-malware software should check every uploaded file and reject ones that fail. The upload filter should accept only certain file types. It needs to reject any files that consist of executable code.
For extra protection, uploaded files shouldn't be directly accessible by URL. They should go into a location which is outside the Web directory. Alternatively, the .htaccess file can make the upload directory inaccessible from the browser. Access to them should be indirect, through an internally generated ID. That lets the server catch improper uses of the files.
Any website that accepts user-provided content needs to have a Web Application Firewall to keep out malicious content and requests. Even the best security measures can let some hostile content through. The rule-based Quttera Web Application Firewall will monitor your site and catch suspicious requests from dubious sources. Quttera's WAF is a part of the ThreatSign security and monitoring system. With ThreatSign protecting your site, you'll have a more reliable website and spend less time fighting with attempts to break it. Every online server needs protection from the many threats on the Internet, and ThreatSign will help to keep your website safe.