File Upload vulnerabilities
Occurs when a web server allows to upload files to his filesystem without sufficiently validating things like name, type, contents or size. If you don’t enforce restrictions on these could mean that even a basic image upload function can be used to upload arbitrary and potentially dangerous files instead. This could even include server-side script files that enable remote code execution.
In the worst case scenario, the file’s type isn’t validated properly, and the server configuration allows certain types of file (such as .php and .jsp) to be executed as code. In this case, an attacker could potentially upload a server-side code file that functions as a web shell, effectively granting them full control over the server.
If the server is also vulnerable to directory traversal then the attacker could upload files to unanticipeted locations. If the filename isn’t validated, the attacker could overwrite critical files simply by uploading a file with the same name. (Think for example, adding your own ssh public key to .ssh).
Another possibilty is of uploading files so big that the server crashes or the service quality is degraded (Denial of service)
How do web servers handle requests for static files?
Historically, website consisted almost entirely of static files that would be served to users when requested. Nowdays, websites are increasingly dynamic and the path of a request often has no direct relationship to the filesystem at all.
The process for handling static files is the same:
- parse the path to identify the file request
- Use the file extension to determine the type of file.
- Compare the file extension to a list of types (MIME types)
Then what happen depends on the filte type and the server’s configuration.
- If the web server is configured to execute a file type, i.e PHP file, then the file will be xecuted and the output may be sent to the client in an HTTP response.
- If the file type is executable, but the server is not configured to execute files of this type, it will generally respond with an error.
- If the file type is non-executable i.e PNG or HTML, then the server may just send the file’s contents to the client in an HTTP response.
Tip: Content-Type
The
Content-typeresponse header may provide clues as to what kind of file the server thinks it has served.
Exploiting unrestricted fil uploads to deploy a web shell
This is the worst possible scenario, it happens when the website allows you to upload server-side scripts, such as PHP, Java or Python files, and is also configured to execute them as code.
A web shell is a malicious script that enables an attacker to execute arbitrary commands on a remote web server simply by sending hTTP requests to the right endpoint.
🎌 Lab: remote code execution via web shell upload
An example of web shell may look like this:
<?php echo system($_GET['command']); ?>This script enables you to pass an aribtraty system command via a query parameter as follows:
GET /example/exploit.php?command=id HTTP/1.1Exploiting flawed validation of file uploads
The previous scenario is rare and unlikely. But just because defenes are in place, that doesn’t mean that they are robust.
Here what to look for:
Flawed file type validation: using insecure content type headers in HTTP
Upload file to change server configuration file:
Obfuscating file extensions
url-encoding, %00 null character, file.php.jpg , exploit%2Ephp and so on.
Flawed validation of file’s contents
Exploiting file upload vulnerabilities without remote code execution
It’s still possible to upload scripts for client-side attacks, like upload HTML files or SVG images that have <script> tags, to create a stored XSS payload.
Uploading files using PUT
It’s possible that some webserver may be configured to support PUT requests, therefore it’s possible to upload malicious files.
How to prevent file upload vulnerabilities
- Check the file extension against a whielist of permitted extensions (input validation)
- Apply same prevetions used for directory traversal like making sure that substring doesn’t contains characters that could be interpreted as directory like
../ - Rename uploaded files
- Write to the filesystem only after the file is fully validated
- Use an established framework that does the job for you