10 File Upload & File Handling Security Assessment

Mission Overview

Welcome to Lab 10 — File Upload & File Handling Security Assessment.

In Lab 09, you assessed how user-controlled content can become unsafe in the browser.

Now you will focus on another high-risk input channel:

Files

File functionality is often more complex than a normal text parameter because the application must safely handle:

• file type

• filename

• extension

• MIME type

• size

• metadata

• storage location

• retrieval

• authorization

• rendering

• server-side processing

• deletion

• download behavior

A secure application must treat an uploaded file as untrusted from the moment it is received until the moment it is deleted.

Mission Goal: Assess whether the training application safely validates, stores, processes, serves, and controls access to uploaded and downloadable files without allowing unsafe content handling or unauthorized file access.

Mission Information

Item	Details
Difficulty	Intermediate
Estimated Time	120–150 minutes
Primary Skill	File Upload Security Assessment
Secondary Skill	File Storage & Retrieval Security
Environment	GoHackersCloud Web Pentesting Lab
Testing Mode	Controlled File Handling Assessment
Primary Outcome	File Upload & File Handling Security Report
Safety Level	Benign Training Files Only

Learning Objectives

By completing this lab, you will be able to:

• map file-related application functionality

• identify upload endpoints

• identify download endpoints

• establish normal upload baselines

• assess allowed file extensions

• assess MIME/content-type validation

• compare declared and actual file type

• evaluate filename handling

• identify filename normalization

• assess file-size controls

• identify upload storage behavior

• assess generated server-side filenames

• validate access controls on uploaded files

• assess direct file retrieval

• review download authorization

• identify dangerous inline rendering behavior

• evaluate file metadata handling

• assess server-side processing

• distinguish file acceptance from exploitability

• document positive controls

• produce evidence-backed findings

Core Methodology

Use:

Map → Baseline → Classify File → Upload Safely → Observe Storage → Validate Access → Assess Processing → Evidence → Report

Expanded:

File Functionality
       │
       ▼
Map Upload / Download Endpoints
       │
       ▼
Establish Normal Baseline
       │
       ▼
Classify Expected File
       │
       ├── Extension
       ├── MIME Type
       ├── Size
       ├── Filename
       └── Purpose
       │
       ▼
Upload Benign Test Files
       │
       ▼
Observe Validation
       │
       ▼
Observe Storage & Naming
       │
       ▼
Validate Retrieval & Authorization
       │
       ▼
Assess Rendering / Processing
       │
       ▼
Document Evidence

The core principle is:

File security does not end when the upload is accepted; validation, storage, processing, retrieval, and authorization all matter.

Part 1 — Confirm Scope

Record:

ASSESSMENT ID:
GHC-WEB-LAB10-001

APPLICATION:

BASE URL:

AUTHORIZED:
Yes

TEST ACCOUNTS:

AUTHORIZED FILE FUNCTIONS:

AUTHORIZED FILE TYPES:

EXCLUDED SYSTEMS:

TEST WINDOW:

Use only benign files created specifically for the lab.

Part 2 — Create the Lab Workspace

Create:

Web-Pentesting-Labs/
└── Lab-10/
    ├── 01-Scope/
    ├── 02-File-Functions/
    ├── 03-Upload-Baselines/
    ├── 04-Extensions/
    ├── 05-MIME-Types/
    ├── 06-Filenames/
    ├── 07-Size-Controls/
    ├── 08-Storage/
    ├── 09-Downloads/
    ├── 10-Authorization/
    ├── 11-Rendering/
    ├── 12-Metadata/
    ├── 13-Processing/
    ├── 14-Positive-Controls/
    ├── 15-Evidence/
    ├── 16-Findings/
    └── 17-Report/

Part 3 — Map File-Related Functionality

Identify functions such as:

Avatar Upload

Document Upload

Attachment Upload

Import

Export

Report Download

Invoice Download

Image Upload

Profile Picture

File Preview

File Delete

Create:

Function	Endpoint	Method	Authentication
Avatar Upload	/profile/avatar	POST	User
Document Upload	/documents/upload	POST	User
File Download	/files/{id}	GET	User
Export	/reports/export	GET	Admin

Part 4 — Create the File Function Register

For each function record:

FILE FUNCTION ID:

FUNCTION:

ENDPOINT:

METHOD:

PURPOSE:

EXPECTED FILE TYPE:

AUTHENTICATION:

EXPECTED ROLE:

STORAGE:
Known / Unknown

RETRIEVAL:
Direct / Controlled / Unknown

Part 5 — Establish a Normal Upload Baseline

Create a harmless training file.

Example:

Filename:
ghc-lab10-baseline.txt

Contents:
GoHackersCloud Lab 10 Training File

Upload through the normal application workflow.

Record:

UPLOAD BASELINE

Endpoint:

Filename:

Extension:

Declared Content Type:

File Size:

Response Status:

Application Message:

Uploaded Successfully:
Yes / No

File Identifier:

Retrievable:
Yes / No

Part 6 — Preserve Baseline Evidence

Capture:

• upload request

• multipart structure if applicable

• response

• file identifier

• rendered application state

• download/retrieval request

Assign:

EV-FILE-001

Part 7 — Understand Multipart Uploads

A typical browser file upload may use:

multipart/form-data

A file part commonly contains:

name
filename
Content-Type
file content

These are separate security-relevant values.

The server should not trust them blindly.

Part 8 — Create the Multipart Profile

Record:

MULTIPART PROFILE

Form Field:

Filename:

Declared Content-Type:

Additional Fields:

Object ID:

CSRF Token:

Upload Endpoint:

Part 9 — Identify Expected File Policy

Record what the application claims to accept.

Example:

Allowed:
PNG
JPEG

Maximum Size:
5 MB

Create:

Control	Documented Value
Allowed extensions
Allowed MIME types
Max size
Filename restrictions
Image dimensions
Authentication

Part 10 — Test a Valid Allowed File

Use a benign file matching the intended type.

For an image upload, use an ordinary small training image.

Record:

VALID FILE TEST

Filename:

Extension:

Content:

Declared MIME:

Accepted:
Yes / No

Rendered:
Yes / No

Stored:
Yes / No

Part 11 — Assess Extension Validation

Using benign test files only, compare:

allowed extension

with:

unsupported harmless extension

For example, if the application accepts image files, compare the intended image extension with a harmless text file.

Record whether the server:

Accepts

Rejects

Renames

Converts

Stores but does not serve

Part 12 — Create the Extension Validation Register

Test	Extension	Expected	Result
EXT-001	Allowed	Accept
EXT-002	Unsupported benign	Reject

Part 13 — Do Not Treat Extension Filtering Alone as Complete Security

An extension is only one file characteristic.

A stronger file-validation model may consider:

Extension
   +
Declared MIME
   +
Actual Content
   +
Application Purpose

Allowed Extension ≠ Safe File Automatically

Part 14 — Assess Declared MIME Type

A browser may send:

Content-Type: image/png

This value is client-controlled.

Record whether the application appears to validate beyond the declared MIME type.

Part 15 — Create the MIME Register

File	Extension	Declared MIME	Result
Baseline PNG	.png	image/png
Text file	.txt	text/plain

Part 16 — Compare Declared and Actual File Type

The application should not rely only on the client-provided:

Content-Type

Use harmless mismatched lab examples to determine whether the server validates file content.

Do not upload executable or malicious content.

Example concept:

Filename suggests image
Declared MIME suggests image
Actual content is benign text

Observe whether the application rejects it.

Part 17 — Create the File-Type Consistency Register

TEST ID:

FILENAME:

EXTENSION:

DECLARED MIME:

ACTUAL BENIGN CONTENT TYPE:

RESULT:

SERVER VALIDATION:
Effective / Weak / Unknown

Part 18 — Understand Magic Bytes / File Signatures

Many formats begin with recognizable structural information.

Applications may inspect file content rather than relying only on:

filename

or:

MIME header

This can improve validation.

Do not attempt to create hybrid malicious files.

Part 19 — Assess Filename Handling

Try safe filenames such as:

ghc-lab10.txt

GHC-Lab-10.txt

ghc_lab_10.txt

training file.txt

Record normalization behavior.

Part 20 — Create the Filename Register

Submitted Filename	Stored Filename	Changed
ghc-lab10.txt
training file.txt

Part 21 — Assess Server-Side Filename Generation

Safer systems often store files using generated identifiers rather than trusting the original filename.

Example concept:

User Filename:
profile-photo.png

Stored:
8f31a6...png

Record:

SERVER-SIDE NAMING

Original Filename:

Stored Filename:

Generated:
Yes / No

Predictable:
Known / Unknown

Original Filename Preserved:
Metadata / Display / Unknown

Part 22 — Assess Special Filename Handling Safely

Use only benign naming variations.

Examples:

spaces

multiple periods

uppercase extensions

long but reasonable filename

Observe:

• rejection

• normalization

• truncation

• renaming

Do not attempt filesystem traversal or OS-specific destructive filename tricks.

Part 23 — Assess Filename Length

Use a moderately long benign filename within normal lab limits.

Record:

FILENAME LENGTH

Submitted Length:

Accepted:

Truncated:

Renamed:

Error:

Do not use extreme lengths intended to exhaust resources.

Part 24 — Assess File Size Controls

Use small benign files.

Compare:

normal file

with:

slightly above documented training limit

only if the lab environment is designed for this.

Record:

SIZE CONTROL

Documented Maximum:

Baseline Size:

Oversize Test:

Rejected:
Yes / No

Status:

Message:

Part 25 — Avoid Resource Exhaustion

Do not upload:

• huge files

• highly compressed files designed to expand massively

• thousands of files

• deeply nested archives

• resource-intensive media

File Size Assessment ≠ Denial-of-Service Testing

Part 26 — Observe Storage Location

After upload, determine how the application references the file.

Examples:

/files/123

/uploads/image-123.png

/api/files/123

Record:

STORAGE PROFILE

File ID:

Retrieval URL:

Direct Static Path:
Yes / No

Application-Controlled Endpoint:
Yes / No

Storage Location:
Known / Unknown

Part 27 — Assess Public vs Protected Storage

Using the authorized training file, determine whether it is accessible:

While authenticated

After logout

From another authorized user

This overlaps with authorization testing.

Part 28 — Build the File Access Matrix

File	Owner	Anonymous	User A	User B	Admin
File A	User A		Yes
File B	User B			Yes

Part 29 — Validate Anonymous File Access

After logout, request the authorized training file.

Record:

ANONYMOUS FILE TEST

File:

Expected:
Protected

Response:

File Returned:
Yes / No

Sensitive Content:
Training data only

Part 30 — Validate Cross-User File Access

Using two authorized lab users:

User A owns File A

User B owns File B

Attempt to retrieve File B while authenticated as User A.

Record:

CROSS-USER FILE TEST

Authenticated As:

Requested File:

Owner:

Response:

File Returned:
Yes / No

Authorization Enforced:
Yes / No

Part 31 — Distinguish File Discovery from File Authorization

Always remember:

File URL Known
      ≠
Authorized Access

The server should still validate whether the requesting identity may access the file.

Part 32 — Assess Download Endpoints

Identify download functionality such as:

/files/{id}/download

/report/download

/invoice/{id}

Record:

DOWNLOAD PROFILE

Endpoint:

File Identifier:

Authentication:

Authorization:

Content-Type:

Content-Disposition:

Filename:

Part 33 — Review Content-Disposition

Common behavior includes:

inline

or:

attachment

A file intended only for download may be safer when served as an attachment.

But context matters.

Do not automatically classify inline as vulnerable.

Part 34 — Assess Content-Type on Download

Record whether the server returns a suitable:

Content-Type

for the file.

Incorrect types may affect browser handling.

Create:

File	Expected MIME	Returned MIME

Part 35 — Assess Browser Rendering

Determine whether uploaded benign content is:

Downloaded

Rendered inline

Previewed

Converted

This matters because browser rendering can introduce additional security considerations.

Part 36 — Build the Rendering Register

File Type	Application Behavior	Browser Behavior
Image	Preview	Image
Text	Download	Text
PDF	Inline/download	PDF viewer

Part 37 — Assess Active-Content Risk Conceptually

Some file formats can contain active or complex content.

The assessment question is:

Does the application permit risky content to be served in a context where the browser may interpret it within the application’s trusted origin?

Do not create malicious active files to prove this in a shared environment.

Part 38 — Assess File Hosting Origin

Record whether uploaded files are served from:

Same application origin

Dedicated file domain

Object storage domain

Signed URL

Unknown

Serving user-controlled content from an isolated origin can reduce some browser-side risks.

Part 39 — Create the File-Origin Register

FILE:

APPLICATION ORIGIN:

FILE ORIGIN:

SAME ORIGIN:
Yes / No

AUTH REQUIRED:

SECURITY RELEVANCE:

Part 40 — Assess Image Processing

If the application processes images, observe whether it:

Resizes

Re-encodes

Creates thumbnails

Removes metadata

Record:

IMAGE PROCESSING

Original:

Processed Copy:

Re-Encoded:
Yes / No

Dimensions Changed:

Metadata Preserved:

Evidence:

Re-encoding can reduce certain risks.

Part 41 — Assess Metadata Handling

Benign files may contain metadata such as:

filename

author

camera/device information

document properties

Determine whether the application preserves or exposes this information.

Do not insert sensitive personal information into test metadata.

Part 42 — Create the Metadata Register

File	Metadata Present	Preserved	Exposed
Image A	Basic lab metadata
Document A	Training author

Part 43 — Assess File Preview Functionality

Preview systems may process files differently from downloads.

Map:

Upload
   ↓
Store
   ↓
Preview Service
   ↓
Browser

Record:

PREVIEW PROFILE

File:

Preview Endpoint:

Server Processing:

Rendered Inline:

Converted:

Authentication Required:

Part 44 — Assess File Conversion

Applications may convert:

Image → Thumbnail

Document → PDF

Media → Preview

Spreadsheet → HTML preview

Record whether:

• original remains available

• converted version gets a new identifier

• access control matches the original

Part 45 — Assess Generated Files

Exports and reports are also file-handling functionality.

Examples:

CSV Export

PDF Report

Invoice

Archive

Verify:

• authorization

• filename

• content type

• download behavior

• sensitive-data scope

Part 46 — Create the Generated File Register

File	Function	Role	Access Control
CSV report	Export	User	Own data
Admin PDF	Report	Admin	Admin

Part 47 — Assess File Deletion

For your own training file:

1. upload

2. verify retrieval

3. delete through the normal interface

4. request the previous file URL again

Record:

DELETE TEST

File:

Deleted:
Yes

Previous URL:

Still Accessible:
Yes / No

Application Record Removed:

Storage State:
Known / Unknown

Part 48 — Assess Replacement / Overwrite Behavior

If the application supports replacing an avatar or document:

Old File
   ↓
Replace
   ↓
New File

Determine whether the old file remains accessible.

Record:

REPLACEMENT TEST

Original File:

Replacement File:

Old URL Still Works:
Yes / No

Expected:

Part 49 — Assess Duplicate Filenames

Upload two harmless files using the same original filename.

Observe whether the application:

Renames

Overwrites

Rejects

Versions

Record:

Upload	Original Name	Stored Result
A	same.txt
B	same.txt

Part 50 — Assess File Ownership Metadata

For an uploaded object, identify whether ownership appears linked to:

Authenticated user

Object/account

Document record

Folder/project

Client-supplied ownership values should not override trusted server-side identity without authorization.

Part 51 — Assess File Description and Metadata Inputs

Upload workflows often include additional fields:

title

description

category

owner_id

folder_id

These remain normal untrusted application inputs.

Authorization and XSS rules still apply.

Part 52 — Identify Positive File Security Controls

Examples include:

Extension allowlist

Content validation

MIME validation

Generated server filename

Maximum size enforcement

Authentication required

Object-level authorization

Separate storage origin

Content-Disposition attachment

Safe Content-Type

Image re-encoding

Metadata stripping

Malware scanning

File lifecycle deletion

Document what works.

Part 53 — Malware Scanning

If the lab application indicates antivirus or malware-scanning functionality, document its presence.

Do not upload actual malware.

Use only designated harmless test mechanisms if explicitly provided by the training environment.

Record:

MALWARE SCANNING

Present:
Yes / No / Unknown

Workflow:

Rejected File Evidence:

Quarantine:
Known / Unknown

Part 54 — Potential Finding Categories

Possible findings include:

Insufficient File-Type Validation

File Content Validation Missing

Unauthorized Cross-User File Access

Anonymous Access to Private Uploaded Files

Unsafe Inline Rendering

Sensitive Metadata Exposure

Deleted File Remains Accessible

Old Replaced File Remains Accessible

Missing File Size Enforcement

Predictable File Storage Combined with Weak Authorization

A finding requires validated security impact.

Part 55 — Finding Example: Cross-User File Access

FINDING ID:
FILE-001

TITLE:
Uploaded Documents Accessible Across User Accounts

SEVERITY:
High
Depending on file sensitivity

CONFIDENCE:
High

OBSERVATION:
User A was able to request a training document belonging to
User B through the application's file retrieval endpoint.

VALIDATION:
The returned file contained the known benign test content
created under User B's account.

IMPACT:
Authenticated users may access files belonging to other users.

EVIDENCE:
EV-FILE-008

RECOMMENDATION:
Enforce server-side object ownership and role authorization on
every file retrieval request.

Part 56 — Finding Example: File-Type Validation Weakness

FINDING ID:
FILE-002

TITLE:
File Upload Validation Relies on Client-Provided File Metadata

CONFIDENCE:
High

OBSERVATION:
The application accepted a benign file whose declared MIME and
filename indicated an allowed format even though the actual file
content did not match that format.

SECURITY IMPACT:
Reliance on client-controlled file metadata may allow files
outside the intended application policy to enter the processing
pipeline.

LIMITATION:
Only harmless training content was used. No executable or
malicious file was uploaded.

RECOMMENDATION:
Validate file type using server-side content inspection,
allowlisted formats, and application-specific parsing.

Part 57 — Finding Example: Private File Accessible Anonymously

FINDING ID:
FILE-003

TITLE:
Authenticated Upload Accessible Without Authentication

SEVERITY:
High
Depending on content sensitivity

CONFIDENCE:
High

OBSERVATION:
A file uploaded through an authenticated private workflow
remained directly retrievable after the test session was removed.

IMPACT:
Anyone who obtains or predicts the file URL may be able to access
content intended for authenticated users.

RECOMMENDATION:
Enforce authentication and authorization at file retrieval time
or use appropriately controlled short-lived access mechanisms.

Part 58 — Finding Example: Deleted File Remains Accessible

FINDING ID:
FILE-004

TITLE:
Deleted File Remains Accessible Through Previous Retrieval URL

CONFIDENCE:
High

OBSERVATION:
After the training file was deleted through the application's
normal interface, the previous file URL continued returning the
file.

IMPACT:
Users may believe content has been removed while the underlying
object remains retrievable.

RECOMMENDATION:
Ensure deletion workflows revoke access to or remove the
underlying stored object according to the application's data
retention requirements.

Part 59 — Avoid False Findings

Do not report:

File upload exists.

as a vulnerability.

Do not report:

PNG files are accepted.

as a vulnerability.

Do not report:

Filename is visible.

as a vulnerability automatically.

Do not report:

Uploaded file has a direct URL.

as a vulnerability unless access control or another security property fails.

Part 60 — Build the Findings Register

Finding	Status	Severity	Confidence
Type validation
MIME validation
Filename handling
Anonymous access
Cross-user access
Unsafe rendering
Deletion lifecycle

Part 61 — Build the File Security Coverage Matrix

Area	Tested	Result
Upload baseline	Yes
Extension validation	Yes
MIME validation	Yes
Actual file-type validation	Yes
Filename handling	Yes
Size controls	Yes
Storage mapping	Yes
Anonymous retrieval	Yes
Cross-user retrieval	Yes
Download headers	Yes
Rendering	Yes
Metadata	Yes
Deletion	Yes
Replacement	Yes/NA
Processing	Yes/NA

Part 62 — Create the Evidence Register

Example:

Evidence ID	Description
EV-FILE-001	Normal upload baseline
EV-FILE-002	Multipart upload request
EV-FILE-003	Extension-validation result
EV-FILE-004	MIME/content mismatch result
EV-FILE-005	Filename normalization
EV-FILE-006	Stored file reference
EV-FILE-007	Anonymous retrieval test
EV-FILE-008	Cross-user authorization test
EV-FILE-009	Download headers
EV-FILE-010	File rendering behavior
EV-FILE-011	Metadata behavior
EV-FILE-012	Deletion validation

Part 63 — Mission Challenge

Complete:

FILE UPLOAD & FILE HANDLING SECURITY ASSESSMENT

Assessment ID:

Analyst:

Date:


SCOPE

Application:

Base URL:

Authorized:
Yes / No

Test Accounts:


FILE FUNCTIONS

Upload:

Download:

Preview:

Export:

Delete:

Replace:


BASELINE UPLOAD

Filename:

Extension:

Declared MIME:

Actual Type:

Size:

Accepted:

Stored:

File ID:


FILE POLICY

Allowed Extensions:

Allowed MIME:

Maximum Size:

Filename Rules:


EXTENSION VALIDATION

Allowed File:

Unsupported Benign File:

Result:


CONTENT VALIDATION

Declared Type:

Actual Type:

Accepted:

Server Content Validation:
Effective / Weak / Unknown


FILENAME HANDLING

Submitted:

Stored:

Renamed:

Normalized:


SIZE CONTROL

Documented Limit:

Observed:

Oversize Rejected:


STORAGE

File URL:

Direct Storage:

Application Endpoint:

Storage Origin:

Same Application Origin:


AUTHORIZATION

Anonymous Access:

User A → User A File:

User A → User B File:

Admin Access:

Result:


DOWNLOAD

Endpoint:

Content-Type:

Content-Disposition:

Filename:


RENDERING

Downloaded:

Inline:

Previewed:

Converted:


METADATA

Preserved:

Exposed:

Removed:


PROCESSING

Image Re-Encoded:

Preview Generated:

Conversion:

Malware Scan:


DELETION

Deleted:

Old URL Works:

Underlying File Accessible:


REPLACEMENT

Old File:

New File:

Old URL Works:


POSITIVE CONTROLS

Control 01:

Control 02:

Control 03:


FINDINGS

Finding 01:

Severity:

Confidence:

Evidence:


Finding 02:

Severity:

Confidence:

Evidence:


LIMITATIONS

Limitation 01:

Limitation 02:


FINAL ASSESSMENT

Upload Validation:
Effective / Weak / Inconclusive

Storage Security:

Retrieval Authorization:

Download Security:

Rendering Security:

File Lifecycle:

Overall File Handling Risk:

Ready for Server-Side Security Assessment:
Yes / No

What Not to Do

Do not:

Upload malware

Upload executable attack tools

Upload web shells

Attempt remote code execution

Attempt filesystem traversal

Attempt operating-system command execution

Upload decompression bombs

Upload extremely large files

Upload thousands of files

Target third-party storage

Access another real user's files

Upload sensitive personal data

Attempt antivirus evasion

Attempt parser exploitation

Use files to establish persistence

Use uploaded files to pivot to other systems

Assume extension acceptance means code execution

Assume direct URLs mean unauthorized access

Continue once sufficient evidence exists

The professional rule is:

Use harmless files to validate security boundaries. You do not need malicious content to prove that validation, authorization, storage, or lifecycle controls are weak.

Professional Distinctions

Always distinguish:

File Uploaded
      ≠
Unsafe File Upload

Unsupported File Accepted
      ≠
Remote Code Execution

Client MIME Accepted
      ≠
File Content Validated

Direct File URL
      ≠
Unauthorized File Access

Predictable Filename
      ≠
Data Exposure Automatically

Same-Origin File
      ≠
Browser Exploitation Automatically

Inline Rendering
      ≠
XSS Automatically

Metadata Preserved
      ≠
Sensitive Metadata Exposure Automatically

File Deleted from UI
      ≠
Underlying Object Deleted

Multiple Extensions
      ≠
Validation Bypass Automatically

Malware Scanner Present
      ≠
File Upload Fully Secure

File Type Allowed
      ≠
File Processing Safe

Evidence Requirements

Capture:

• assessment scope

• File Function Register

• valid upload baseline

• multipart request

• expected file policy

• allowed-file test

• unsupported benign-file test

• extension-validation result

• MIME-validation result

• declared/actual file-type comparison

• filename handling

• generated-filename behavior

• file-size controls

• storage profile

• retrieval URL

• anonymous access test

• cross-user file access test

• file access matrix

• download headers

• Content-Type behavior

• Content-Disposition behavior

• browser-rendering behavior

• storage-origin profile

• metadata handling

• preview/processing behavior

• generated-file behavior

• file deletion validation

• replacement behavior where applicable

• positive controls

• findings register

• coverage matrix

• evidence register

Mission Deliverables

Complete:

• scope confirmed

• file functionality mapped

• normal upload baseline established

• multipart upload understood

• application file policy documented

• allowed file validated

• unsupported benign file tested

• extension validation assessed

• MIME validation assessed

• actual file-type validation assessed

• filename handling assessed

• server-side filename generation assessed

• filename normalization documented

• file-size controls assessed

• storage location mapped

• file retrieval mapped

• anonymous access assessed

• cross-user access assessed

• download authorization assessed

• Content-Type reviewed

• Content-Disposition reviewed

• rendering behavior assessed

• file storage origin reviewed

• image/document processing reviewed where applicable

• metadata handling assessed

• generated/exported files reviewed

• deletion lifecycle assessed

• replacement behavior assessed where applicable

• malware scanning documented where available

• positive controls documented

• findings validated

• severity and confidence assigned

• evidence preserved

• final File Handling Assessment completed

Lab Report Template

# Lab 10 — File Upload & File Handling Security Assessment

## Executive Summary

## Mission Objective

## Authorization & Scope

## File Functionality Map

## Upload Baseline

## File Policy

## Extension Validation

## MIME Type Validation

## Actual File Content Validation

## Filename Handling

## Filename Generation

## File Size Controls

## Storage Architecture

## File Retrieval

## Anonymous Access

## Cross-User Authorization

## Download Security

## Content-Type

## Content-Disposition

## Browser Rendering

## File Hosting Origin

## Metadata Handling

## File Preview & Processing

## Generated Files & Exports

## File Deletion

## File Replacement

## Malware Scanning

## Positive Security Controls

## Findings

## Severity & Confidence

## Evidence Register

## Limitations

## Recommendations

## Conclusion

Knowledge Check

Question 1 — Why is file upload security more than extension validation?

Because the application must also consider actual content, MIME type, filename, size, storage, retrieval, authorization, processing, and rendering.

Question 2 — Can the application trust the file’s Content-Type header?

No.

It is supplied by the client and should not be the only validation mechanism.

Question 3 — Does accepting an unsupported file prove code execution?

No.

It demonstrates a validation issue only if the intended file policy is bypassed; code execution requires separate evidence.

Question 4 — Why generate server-side filenames?

It can reduce filename collisions, user-controlled path issues, and predictable storage behavior.

Question 5 — Does a direct file URL automatically mean a vulnerability?

No.

The security question is whether the file can be accessed by identities that should not have permission.

Question 6 — Why test file retrieval after logout?

To determine whether a supposedly protected file actually requires authentication.

Question 7 — Why test cross-user file access?

Because file storage requires object-level authorization just like any other user-owned resource.

Question 8 — Why assess deletion?

Because removing a file from the UI does not necessarily mean the stored object can no longer be retrieved.

Question 9 — Is a malware scanner enough to secure uploads?

No.

It is one defensive layer alongside validation, authorization, safe storage, processing, and retrieval.

Question 10 — What is the central question?

“Does the application treat uploaded files as untrusted content throughout validation, storage, processing, retrieval, and access control?”

Skills Achieved

After completing this lab, you should understand:

• upload endpoint mapping

• multipart file handling

• extension validation

• MIME validation

• actual file-type validation

• filename normalization

• generated filenames

• file-size controls

• storage architecture

• file retrieval

• file authorization

• anonymous access testing

• cross-user access testing

• download headers

• inline rendering

• file-origin security

• metadata handling

• preview/conversion security

• deletion lifecycle

• evidence-driven reporting

Professional Takeaway

A weak file-upload assessment looks like:

Upload File
    ↓
Accepted
    ↓
Upload Vulnerability

A professional assessment looks like:

Map File Functionality
        ↓
Establish Valid Baseline
        ↓
Understand File Policy
        ↓
Assess Extension
        ↓
Assess Declared MIME
        ↓
Assess Actual Content
        ↓
Assess Filename Handling
        ↓
Assess Size Controls
        ↓
Map Storage
        ↓
Validate Authentication
        ↓
Validate Object Authorization
        ↓
Assess Download Handling
        ↓
Assess Browser Rendering
        ↓
Assess Processing
        ↓
Assess Deletion Lifecycle
        ↓
Evidence
        ↓
Report

What’s Next?

➡️ Lab 11 — Server-Side Request & Backend Security Assessment

In the next lab, you will move from file processing to how the application interacts with backend resources and server-side destinations.

You will assess:

• URL-accepting functionality

• server-side fetch behavior

• image import

• webhook-like workflows

• remote-resource previews

• redirect handling

• URL validation

• scheme restrictions

• destination allowlisting

• DNS and hostname handling concepts

• internal/private destination protections

• backend error behavior

• server-side trust boundaries

• safe outbound-request validation

• evidence and reporting

The methodology becomes:

Map → Baseline → Classify Destination → Validate URL Controls → Observe Server Behavior → Assess Boundary → Evidence → Report

The central question will be:

“Can user-controlled destination information cause the application server to make requests outside the network locations and services it is intended to reach?”