A secure server should not only prevent dangerous files from being uploaded (like .php, .jsp), but also ensure that uploaded files are never executed, even if malicious ones slip through. This is often achieved by placing uploaded files in non-executable directories or disabling script execution in those paths.
However, if an attacker can bypass the intended upload location, for example by exploiting path traversal via the filename parameter in a multipart/form-data upload request, they may be able to:
- Upload a script to a sensitive directory
- Trick the server into executing it
Lab: Web shell upload via path traversal | Web Security Academy
In this scenario, the application includes an image upload feature that is vulnerable to a directory traversal flaw. Although the server is set up to block direct execution of user-uploaded files, this defense can be circumvented by taking advantage of the path traversal issue.
Your objective is to upload a simple PHP-based web shell and use it to access and extract the contents of the file located at /home/carlos/secret. Once retrieved, submit the secret using the interface provided at the top of the lab page.
You can log in to your user account with these credentials: Username: wiener, Password: peter
Secure Upload Directory – Script Not Executed
1. A website allows users to upload profile pictures.
Uploaded files are stored in:
/files/avatars/<YOUR-IMAGE>
This directory is configured not to execute scripts (PHP, JSP, etc.).
Server config (e.g., .htaccess) disables PHP execution:
php_flag engine off
2. Now we upload an exploit.php file instead of an image:
<?php echo file_get_contents(‘/home/carlos/secret’); ?>
The server receives and stores the file, but in a directory where PHP execution is disabled.
3. When the attacker tries to run the file:
/files/avatars/exploit.php
Instead of executing, the server responds with plain text:
This implies:
- The server treats it as a plain text file, not code.
- This prevents remote code execution.
- It may still leak source code — but execution is blocked, which is the priority.
Bypassing File Execution Prevention
Some applications allow users to control the filename and do not sanitize directory traversal patterns (../). This means the attacker can trick the server into saving the file in a different directory — one where script execution is enabled.
- Modify the filename to perform directory traversal and target an executable directory,
../exploit.php
This did not upload the file into the parent directory, as the file was uploaded into /files/avatars dir. This means ../ might be blacklisted.
2. So let’s encode the ../ in the filename
%2e%2e%2fexploit.php
Now it was uploaded in the parent directory, as we can see in the response – avatars/../exploit.php.
- Parent directory has no upload protections and allows PHP execution. Let’s access the file from that location.
/files/avatars/../exploit.php
How does this vulnerability arise?
This is a combination of two issues:
- Misconfigured Directory Permissions
- Some directories allow script execution, others don’t.
The filename field in multipart/form-data is user-controlled. If not sanitized, attackers can escape the intended folder and drop files anywhere they want.
This lets attackers:
- Upload scripts
- Choose their destination
- And get Remote Code Execution
Conclusion
Even if your upload directory is configured to prevent script execution, trusting user input for filename or path can still allow attackers to escape the safe zone. When combined with directory traversal, attackers can upload malicious scripts to executable directories, leading to full Remote Code Execution (RCE).
The key defense is to treat all user inputs as dangerous, especially file names and paths. Always sanitize, validate, and isolate uploaded files in secure, non-executable zones.
