File upload modules are one of the weakest links in web applications. Any mistakes made, even ones you consider to be small, could result in server control falling directly into a cyberattacker's hands. For this reason, software developers need to know the most common mistakes and some attack methods that can occur.

So what is client side tampering? How can you combat this to keep your sites, and your users, safe?

What Is Client Side Tampering?

Client-side tampering is the basic concept of web application attacks as a whole. Simply put, it means that you can no longer trust any of the data you send to the user. In addition, client-side tampering is one of the foundations of secure application development. If you examine the file upload module you are dealing with and consider client-side tampering, the data you cannot trust includes:

  • The name of the uploaded file.
  • The Content-Type of the uploaded file.

These two items are where you have the opportunity to whitelist as a software developer. The name data of the uploaded file can contain anything with client-side tampering. With the Content-Type data of the uploaded file, even if the attacker is uploading a .exe file, this file may appear as an image/jpeg in the system.

File Extension and White Listing

Checking the file extensions uploaded to the system

While developing file upload modules, the first thing to do is the whitelisting process for the file extension. For example, a user wants to upload a file named "muo.jpeg". You must make sure that this file extension that the user wants to upload is .jpeg. For this, the system should check the uploaded file and see if it's one of the allowed file extensions. To understand how you can do this, examine the following simple PHP code:

        $file_parts = pathinfo($filename);
switch($file_parts['extension'])
{
    case "jpg":
    break;

    case "bat": // Or exe, dll, so, etc.
    break;

    case "":
    case NULL: // No file extension
    break;
}

You can do this with a code block similar to the one above, or you can use the classes and functions provided by the framework you are using.

Be careful not to create file extension data by parsing the filename according to the dot (.) character, because the attacker can bypass this check step with a file name such as "muo.jpeg.php".

What Is Content-Type Information?

Content-Type information is a piece of information sent in the HTTP request for each file upload. The internet browser detects this info and adds it to the sent request. The attacker can try to change the information with client-side tampering and bypass server-side validations. At this stage, developers need a control mechanism to make validations over the Content-Type information. This alone will not be enough; still, it's an important issue for developers to pay attention to.

Let's say you encode a mechanism to check the file extension correctly, and you only accept files with the .jpeg extension. In addition to this precautionary mechanism, you can check the Content-Type information just in case and only accept files with image/jpeg information, an extra level of protection against cyberattacks

SWF Flash Files and Attack Steps

The file extension and Content-Type data mean nothing to internet browsers that support plug-ins such as Adobe Flash Player. Although support for that player is no longer available, it is still possible to install those related files on many systems, even though Flash remains a security risk. In a system that hasn't taken the relevant precautions, it is possible to call a Flash file with the <object> tag, regardless of its extension. This will cause another serious security problem.

end of life plug in website advice

In order to take action, developers need to know the pathways cybercriminals can take. Here's how it can happen:

  1. The malicious attacker uploads an SWF (an Adobe Flash file format) named "image.jpeg" to the target website. During the upload process, it is confirmed in the whitelisting verification that the file uploaded by the attacker has a .jpeg extension. Content-Type verification is bypassed with client-side tampering. Imagine this file, uploaded by the threat actor, goes to "www(dot)target-site(dot)com/images/images.jpeg".
  2. Let's say the attacker has a website called attacker(dot)com. The attacker calls the image.jpeg file uploaded to the target site on this website, using the <object> tag with the application/x-shockwave-flash type assignment.
  3. An innocent user logs into attacker(dot)com. That site calls up the SWF file at www(dot)target-site(dot)com/images/image.jpeg and executes the commands given to the SWF.
  4. Through this, the cyberattacker can create HTTP request actions for the target-site(dot)com address without normal users noticing. With these requests, the attacker will use the session of the innocent user and bypass the CSRF check.

To understand this attack scenario more clearly, consider the following code to be in the HTML <object> content sent to the user by attacker(dot)com:

        style="height:1px;width:1px;" data="www.target-site.com/images/image.jpeg" type="application/x-shockwave-flash" allowscriptaccess="always" flashvars="c=read&u=somethings"

One of the best solutions is to access the files uploaded with file upload via a different subdomain. In the aforementioned scenario, you can access static files not from the same domain, but from a different subdomain as follows: "http(colon)//file.target-site(dot)com/images/image.jpeg".

Another solution is to add Content-Disposition: attachment information to the HTTP response when you receive a request for access to the files you want to upload.

Take Precautions for File Upload Vulnerabilities

Any file upload that users can make to a website is dangerous, so this is one of the issues that developers should pay the most attention to. If attackers discover such a vulnerability, they can open a shell within the site and easily exploit the information on the server. It's vitally important to control all files uploaded by users, apply whitelist methods, and hide the location of the uploaded directory if possible.

And of course, there are many other additional steps you must take to protect your site, even if you take all the advised precautions to upload file modules. Using HTTP security headers is one such step you can take.