- CWE-22: Path Traversal
- CWE-78: OS Command Injection
- CWE-79: Cross-Site Scripting
- CWE-89: SQL Injection
- CWE-90: LDAP Injection
- CWE-91: XML Injection
- CWE-94: Code Injection
- CWE-98: PHP File Inclusion
- CWE-113: HTTP Response Splitting
- CWE-119: Buffer Errors
- CWE-130: Improper Handling of Length Parameter Inconsistency
- CWE-193: Off-by-one Error
- CWE-200: Information Exposure
- CWE-211: Information Exposure Through Externally-Generated Error Message
- CWE-236: Improper Handling of Undefined Parameters
- CWE-276: Incorrect Default Permissions
- CWE-284: Improper Access Control
- CWE-285: Improper Authorization
- CWE-287: Improper Authentication
- CWE-297: Improper Validation of Certificate with Host Mismatch
- CWE-306: Missing Authentication for Critical Function
- CWE-312: Cleartext Storage of Sensitive Information
- CWE-345: Insufficient Verification of Data Authenticity
- CWE-352: Cross-Site Request Forgery
- CWE-384: Session Fixation
- CWE-427: Uncontrolled Search Path Element
- CWE-434: Unrestricted Upload of File with Dangerous Type
- CWE-476: NULL Pointer Dereference
- CWE-521: Weak Password Requirements
- CWE-601: Open Redirect
- CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
- CWE-613: Insufficient Session Expiration
- CWE-618: Exposed Unsafe ActiveX Method
- CWE-671: Lack of Administrator Control over Security
- CWE-798: Use of Hard-coded Credentials
- CWE-799: Improper Control of Interaction Frequency
- CWE-822: Untrusted Pointer Dereference
- CWE-835: Infinite Loop
- CWE-918: Server-Side Request Forgery (SSRF)
- CWE-942: Overly Permissive Cross-domain Whitelist
CWE is a trademark of the MITRE Corporation.
Unrestricted Upload of File with Dangerous Type [CWE-434]
Arbitrary file upload weakness describes improper or absent validation of file types when uploading files.
Created: September 11, 2012
Latest Update: June 26, 2019
Table of Content
- Potential impact
- Attack patterns
- Affected software
- Exploitation Examples
- Severity and CVSS Scoring
- Latest Related Security Advisories
This weakness occurs when application does not validate or improperly validates files types before uploading files to the system. This weakness is language independent but mostly occurs in applications written in ASP and PHP.
A file of dangerous type is a file that can be automatically processed within the product's environment. The following example demonstrates upload of a PHP file:
- <form action="upload_image.php" method="post" enctype="multipart/form-data">
- <input type="file" name="filename"/>
- <input type="submit" name="submit" value="Upload"/>
- // Unrestricted Upload of File with Dangerous Type [CWE-434] vulnerable code example
- // (c) HTB Research
- $image = "images/". basename($_FILES["uploadedfile"]["name"]);
- if(move_uploaded_file($_FILES["uploadedfile"]["tmp_name"], $image))
- echo "You have successfully uploaded you picture.";
- echo "Error!";
The above code does not perform any checks on uploaded file and uploads this file within the web root directory. As a result an attacker might be able to upload arbitrary PHP file and execute it by directly accessing the uploaded file.
2. Potential impact
An attacker might be able to upload and execute arbitrary code on the target system which could result in execution of arbitrary HTML and script code or system compromise.
3. Attack patterns
There are following CAPEC patterns for this weakness:
- CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
- CAPEC-122: Exploitation of Authorization
This weakness is not described as an attack technique in WASC Threat Classification database.
4. Affected software
Any software that allows files uploads is potentially vulnerable to this weakness.
5. Exploitation Examples
We will use the HTB23079 security advisory (CVE-2012-1468) as an example of this weakness. Open Journal Systems does not properly verify file extension before uploading files. A remote authenticated user can upload files with dangerous extension within the web root directory. Since registration is open by default, an attacker can register to the application and perform a successful attack.
Let's create the exploited as described in the advisory:
After that we log in into the application and create a new Submission. On step 2 we upload our file:
As we can see, the file was uploaded and renamed to "23-43-1-SM.pHp". Now we can access this file directly using the following URL:
Since this file has a .pHp extension, it is treated as a regular PHP file by the webserver. The following image shows successful execution of our PHP code on the target server:
6. Severity and CVSS Scoring
This weakness should be scored depending on the maximum potential impact. If upload of arbitrary PHP file is possible it should be scored as:
10 (AV:N/AC:L/Au:N/C:C/I:C/A:C) - Critical severity.
If authentication is required to exploit this vulnerability but registration is open by default and any registered user can upload files with dangerous types it should be scored as Au:N otherwise as Au:S or Au:M depending on required privilege level and authentication schemes.
We use CVSSv2 scoring system in our HTB Security Advisories to calculate the risk of the discovered vulnerabilities. Not all of the vulnerabilities are scored in strict accordance to FIRST recommendations. Our CVSSv2 scores are based on our long internal experience in software auditing and penetration testing, taking into consideration a lot of practical nuances and details. Therefore, sometimes they may differ from those ones that are recommended by FIRST.
To avoid exploitation of this weakness, developers should consider the following recommendations:
- Store uploaded files outside of the web root directory when possible.
- Use randomly generated filenames for uploaded files.
- Ensure that only one extension is used in the filename. Consider cross-site scripting possibility if you allow upload of html files.
- On case-insensitive systems ensure that case-insensitive evaluation of the file extension is performed.
- Check for the correct MIME type of the file before uploading it but do not exclusively rely on the MIME type.
- When possible ensure that only files with allowed extensions can be directly accessed from the upload directory, for example restrict access to any PHP/ASP files within a directory if it should only contain images.
- CWE-434: Unrestricted Upload of File with Dangerous Type [cwe.mitre.org]
- Unrestricted File Upload [owasp.org]
9. Unrestricted Upload of File with Dangerous Type Vulnerabilities, Exploits and Examples
- HTB23239: Arbitrary File Upload in HelpDEZk
- HTB23218: Unrestricted Upload of File with Dangerous Type in BoltWire
- HTB23199: Multiple Vulnerabilities in VideoWhisper Live Streaming Integration WP Plugin
- HTB23079: Multiple vulnerabilities in Open Journal Systems (OJS)
Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.↑ Back to Top