1. Principles:

When an application fails to rigorously validate the type, content, or size of user-uploaded files — or when its validation logic contains flaws — an attacker can disguise a malicious script (e.g., a PHP or JSP web shell) and upload it to the server. By directly accessing the uploaded file via URL or exploiting a file inclusion vulnerability, the attacker can execute the script and take control of the server.

Direct Impact:

• Obtain a WebShell and gain full control over the server and database.
• Deface web pages, inject malicious backlinks, or publish illegal content.
• Pivot laterally into the internal network and exfiltrate sensitive data.

Indirect Impact:

• Uploading HTML/SVG files can lead to stored XSS.
• Uploading large files can exhaust disk resources (Denial of Service).
• Overwriting system configuration files.

2. Common Upload Entry Points

• Avatar, photo album, and attachment uploads
• Image/video insertion within article editors
• Template and compressed archive imports in admin backends
• File manager and backup/restore interfaces
• API endpoints, such as Excel file uploads for data import

3. Common Detection Methods and Bypass Techniques

3.1 Client-Side JavaScript Detection

Typically checks the file extension.

Behavior: Only validates the extension or file size in the browser, displaying a pop-up alert.

Bypass: Upload an allowed file type, then intercept and modify the file extension using a packet capture tool.

Example: disable JavaScript, intercept and tamper with the request using Burp Suite, and send a .php file directly.

3.2 Server-Side MIME Type Detection

3.2.1 MIME (Multipurpose Internet Mail Extensions)

MIME types define how files with a given extension should be opened by an application. When a file with that extension is accessed, the browser automatically designates which application to use. MIME types are commonly used to specify custom client-side file names and the opening methods for media files.

For instance, a browser's MIME Sniff feature determines a file's type by reading its first 256 bytes.

Each MIME type consists of two parts: the first part indicates the broad data category (e.g., audio, image), while the second specifies the concrete type.

3.2.2 Common MIME Types

Behavior: Only the Content-Type header is checked. If you manually change it to image/jpeg, the file body can still contain PHP code.

Bypass Techniques:

• Upload an allowed MIME type, change the filename parameter to a script extension, and place the WebShell payload inside the request body.
• • Method 1: directly forge a GIF89A header.
  • Method 2: use the CMD command: copy /b test.png+1.php muma.png
  • Method 3: use a tool to append a one-liner web shell in the file's metadata.

3.3 Server-Side File Extension Detection

Blacklist: Bypass by varying filename case or using an extension not present in the blacklist, such as .cer.

Whitelist: Exploit parsing vulnerabilities or use excessively long filenames to evade detection.

0x00 (Null Byte) Truncation:

• Principle: in common string-processing functions of languages like C and PHP, 0x00 is treated as a terminator.
• Hexadecimal: 0x00, URL-encoded as %00
• Payload: For affected web applications and servers, you can craft a filename like test.php[\0].jpg (modified inside the POST request, where [\0] is the hexadecimal 0x00 character). This bypasses the application's file type check, but on the server side, the filename is truncated at the null byte, ultimately becoming test.php.
• Code Walkthrough:
• • name = getname(http request) // Suppose the filename obtained at this point is test.asp.jpg (with 0x00 after 'asp')
  • • type=gettype(name) // The gettype() function scans extensions from right to left, so it identifies .jpg if (type==jpg) SaveFileToPath(UploadPath.name, name) // But here, the filename is truncated at 0x00, so the file is saved as test.asp on disk.

.htaccess file: Modifying this configuration file can force files in a specific directory to be parsed with a designated handler.

• This parsing vulnerability can only be exploited after gaining server access, so it is typically used to plant backdoors.
• If .htaccess is executable and uploadable in Apache, you can write the following inside .htaccess:

<FilesMatch "xxx.jpx"> SetHandler application/x-httpd-php </FilesMatch>

• Then upload a trojan named shell.jpg — it will be parsed as a PHP file.

Rename the file to test.asp. or test.asp_ (the underscore here denotes a trailing space).

• This naming convention is not permitted on Windows, so you need to modify the filename using a tool like Burp Suite. After bypassing validation, Windows will automatically strip the trailing space. Note that Unix/Linux systems do not have this behavior.

:$DATA Bypass

• This is a feature of the NTFS file system on Windows. When you request the DATA attribute of an NTFS file system's data stream:
• • a.asp::$DATA directly retrieves the raw data of a.asp itself (e.g., its source code).
  • If a.asp contains an alternate data stream named lake2.asp, then requesting a.asp.lake2.asp::$DATA can retrieve the data hidden in that stream.

3.4 Server-Side File Content Detection

Checks whether the file content is legitimate or contains malicious code.

Encrypt the malicious code before uploading to bypass content inspection.

3.5 Web Application Parsing Vulnerabilities

3.5.1 Apache Parsing Vulnerability

Cause: Apache 1.x and 2.x have a file parsing issue: Apache parses filenames from right to left, continuing until it encounters a file type it recognizes.

Example: test.php.rar.rar

• Apache does not recognize the .rar file type, so it traverses leftward until it hits .php, treats the file as a PHP script, and executes it.

3.5.2 IIS Parsing Vulnerability (Internet Information Services)

Parsing Issues:

• Semicolon Truncation
• • Cause: under IIS 6 and Windows, a similar truncation issue exists during file parsing, except the truncating character is the semicolon (;).
  • Example (Payload): adc.asp;xx.jpg
  • • IIS 6 parses this file as adc.asp, truncating the trailing xx.jpg, which leads to script execution.
• *.asp Directory Parsing
• • Cause: due to an error in handling file extensions, all files under a directory named /*.asp/ are parsed as ASP files.
  • Example (Payload): http://www.test.com/path/app.asp/abc.jpg
  • • Here, abc.jpg is a JPEG file, but it gets parsed as an ASP file.
• Note: both IIS parsing vulnerabilities require the corresponding file or folder to physically exist on the server's local hard drive. They cannot be triggered if the URL is merely mapped through the web application.

Configuration Issues:

• Overview: many web servers disable the PUT method by default or strictly restrict uploadable file types. However, in IIS, if a directory has write permissions and WebDAV is enabled, the PUT method is supported. Combined with the MOVE method, an attacker can rename a file originally restricted to text-only uploads into a script file, thereby executing a WebShell.
• Prerequisites:
• • The directory in IIS must have write permissions.
  • WebDAV must be enabled.
  • The IIS server must have the “Script Resource Access” checkbox enabled.
• Exploitation Method:
• • Probe the server's supported HTTP methods using the OPTIONS verb.

PUT /test.txt HTTP 1.1
HOST:www.test.com
​
<%eval(request("cmd"))%>
​
// 上传包含恶意脚本的文本文件

MOVE /test.txt HTTP 1.1
HOST:www.test.com
Destination:http://www.test.com/path/shell.php
​
//通过MOVE改文件名

3.5.3 Nginx Parsing Vulnerability

Cause:

• When Nginx is configured with fastcgi to serve PHP, a file parsing issue can occur.
• • This vulnerability stems from the way PHP obtains environment variables under fastcgi mode.
  • There is a critical option in PHP's configuration file:
  • • cgi.fix_pathinfo = 1, which is enabled by default. When mapping URLs, PHP recursively traverses the path to validate file existence. If notexist.php does not exist, it moves up the path. This feature was originally designed so that a URL like /info.php/test would correctly resolve to info.php. At this point, SCRIPT_FILENAME needs to check whether the file exists, so it becomes /path/test.jpg. Meanwhile, PATH_INFO still holds notexist.php. During final execution, test.jpg gets parsed as PHP.
  • Payload:
  • • http://www.test.com/path/test.jpg/notexist.php
    • Here, notexist.php does not actually exist. If you upload an image to any fastcgi-configured PHP application and the image content is PHP code, it will lead to code execution. The same applies to other uploadable legitimate files, such as text files or compressed archives.

4. Exploitation Strategies When the Upload Path Is Not Disclosed

• Attempt to brute-force sensitive files to check for information leaks. If you can locate the source code, perform a direct code audit to see whether the file upload path can be found.
• Brute-force directories for paths like /uploads or /image. Then, based on known information — such as the names of HTML pages — construct paths and continue brute-forcing. If a 403 error is returned, the directory likely exists. Afterwards, try to guess the uploaded filename. (Generally, uploaded files are renamed; if they aren't, that makes things easier. If the original filename returns a 404, it was probably renamed.)
• Trigger application errors that reveal the path.
• • union select 1,2,hex(load_file("D:\\phpstudy_pro\\WWW\\sqli-labs\\Less-1\\index")) -- -
• Nowadays, most sites employ a separation of web server and file storage, or use third-party file storage services such as Alibaba Cloud OSS or Qiniu Cloud. When server and storage are separated, obtaining the file system address is of little use. Third-party storage services generally have robust security, making them difficult for average novices to bypass — for example, storage bucket takeover.

5. Security Hardening

• The most effective measure: set the upload directory as non-executable. On Linux, revoke the 'x' permission on the directory. In practice, many large websites place upload applications on isolated storage and serve files as static assets. This facilitates caching and acceleration to reduce overhead, while also eliminating the possibility of script execution.
• File type checking: a whitelist approach is strongly recommended, combined with MIME type and extension checks (i.e., only explicitly allowed file types may be uploaded). Additionally, for image processing, use compression or resize functions — this processes the image while also destroying any embedded HTML code.
• Rewrite filenames and paths using random values so that users cannot easily access their own uploaded files.
• Host the file server on a separate, dedicated domain.
• • Due to the browser's same-origin policy, many client-side attacks will be rendered ineffective.