Photo by Markus Spiske on Unsplash

What Vulnerabilities We Get from a File Upload

Lately, I’ve transitioned my preferred vulnerability testing focus from user input to examining the upload functionality. This shift occurred as I’ve recently been engrossed in a project, prompting me to extensively explore the Internet for diverse scenarios. This exploration significantly augmented my understanding of file upload functionality.

In this article, I will elucidate the various vulnerabilities that you can assess when encountering a file upload functionality.

The vulnerabilities we are going to discuss include:

1. Exif Metadata Not Removed
2. XSS via Image Metadata
3. HTML Injection via File Name
4. XSS via File Name
5. Unrestricted File Upload
6. Pixel Flood attack
7. Size Restriction
8. XXE by File upload
9. RCE by PHP File Upload
10. Webshell Execution by PHP file upload
11. Open Redirect by SVG File Upload
12. XSS by SVG File Upload

Exif Metadata Not Removed

Upload the image file which contains the metadata. Upon successful upload, download the image file and utilize an online website or the Exif tool to determine whether the metadata has been removed or not.

XSS via Image Metadata

Install the Exiftool on your system to generate the payload for executing this attack. After installing the tool, use the following command to inject the XSS payload into the image metadata:

exiftool -Comment='"><img src=x onmouseover=alert(1)>' /path/to/image.jpg

You might find this excellent Medium article on the subject worth reading. https://shahjerry33.medium.com/xss-via-exif-data-the-p2-elevator-d09e7b7fe9b9

HTML Injection via File Name

I’ve come across a fascinating vulnerability. Some developers preview the uploaded image or PDF and display the file name along with it. In this scenario, we can manipulate the file name by introducing HTML tags.

The name of the file is “tests<br>sdfsdf.jpg”

XSS via File Name

Similar to the previously mentioned HTML Injection attack, we can attempt to insert the XSS payload into the file name and then upload it.

Unrestricted File Upload

Every upload functionality serves a specific purpose, and based on that purpose, only certain file types should be allowed. For instance, on a website with a user profile feature allowing image uploads, only image files should be permitted, excluding other file types like PHP or HTML.

To circumvent such checks, one strategy is to attempt to change the file’s MIME type to one permitted by the server. Additionally, we can assess whether the file extension is blacklisted by altering the extension of a PHP file to variations such as .PHP, .pHp, .PhP, .php5, or other combinations.

Pixel Flood attack

Another intriguing file upload attack involves using a specific image file as a payload. When this file is uploaded to the server, it causes the server to crash during the image loading process. You can read more about this over here https://shahjerry33.medium.com/dos-mr-pixel-flood-27605add29f2

Size Restriction

As explained in the context of the Unrestricted File Upload vulnerability, file sizes should be determined based on their intended purpose, and no file exceeding the defined size limit should be allowed. For instance, an image file for a profile should not exceed 5 MB. This is what we can check by uploading a file of greater size which might cause a DOS attack on the storage level.

XXE by File upload

XXE stands for XML External Entity injection, a well-known attack. If the upload functionality permits the uploading of SVG files, we can then assess for this vulnerability.

Save the payload into an SVG file. This particular payload is designed to read the contents of the /etc/passwd file.

RCE by PHP File Upload

Remote Code Execution is one of the widely known attacks involving a PHP file. In this method, we upload a PHP file containing the payload that executes code on the server.

<?php
$output = shell_exec('ls -la');
echo "<pre>$output</pre>";
?>

The provided PHP payload executes the “ls -la” command on the server and displays the output. You can read here about my RCE finding How I got my first RCE

Webshell Execution by PHP file upload

To establish a reverse shell using a PHP file, we can leverage the Weevely tool for the generation of payload and connection. Additionally, online PHP payloads are available, and we can utilize Netcat to listen for the connection. It’s essentially an expanded version of Remote Code Execution through PHP File Upload.

Open Redirect by SVG File Upload

If the upload functionality permits SVG files, you can employ this payload within an SVG file and upload it to the server. Upon successful upload, accessing the SVG file will redirect you to the Google page.

<svg width="200" height="200"
 onload="window.location='http://google.com'"
  xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
  <image xlink:href="https://upload.wikimedia.org/wikipedia/commons/4/42/Shaqi_jrvej.jpg" height="200" width="200"/>
</svg>

XSS by SVG File Upload

Similar to the above vulnerability, we can use the SVG to trigger XSS. To achieve this, adjustments need to be made to the payload, resembling something like the following:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" baseProfile="full" xmlns="http://www.w3.org/2000/svg">
   <rect width="3200" height="6400" style="fill:rgb(0,0,255);stroke-width:3;stroke:rgb(0,0,0)" />
   <script type="text/javascript">
      alert("XSS Alert");
   </script>
</svg>