Skip to main content

File Upload

Lab: DVWA
Scenario: Unrestricted File Upload
Difficulty: Advanced
Estimated Time: 40 minutes

Learning Objectives​

By the end of this scenario, you will be able to:

  • Show how server-side execution can follow from uploading content the app treats as a static file in a web-accessible path.
  • Contrast client-side checks (JavaScript, accept attribute) from server-side validation.
  • Propose storage outside web root, content inspection, and type verification as defenses.

Setup​

Prerequisites​

  • DVWA at CSN Labs
  • Security Low for the clearest exploit path
  • Text editor to create a small PHP test file (lab environment only)

Initial configuration​

  1. Log into DVWA; set security to Low.
  2. Open Vulnerabilities → File Upload.

Scenario story​

Applications often let users upload images or documents. If the server stores files under the web root and the web server executes PHP (or another language) in that directory, uploading a malicious script can lead to remote code execution. Your goal is to prove the chain in a controlled way.

Step-by-step walkthrough​

Step 1: Baseline upload​

Create a harmless file test.txt with plain text. Upload it.

Expected: The app confirms upload and may show a path or link to the file. Note the URL pattern (often under hackable/uploads/ or similar in DVWA).

Step 2: Attempt a minimal PHP probe​

Create info.php:

<?php phpinfo(); ?>

Upload it.

Expected (Low): Upload succeeds. Open the provided link or browse to the file URL.

If execution works: You see the PHP info page, proof the server executes PHP in that directory.

If blocked: Read the error message, filters often reject extension, MIME type, or content.

Step 3: Understand the trust mistake​

Vulnerable patterns include:

  • Trusting Content-Type from the client.
  • Allowing double extensions (file.php.jpg) or null bytes (older parsers).
  • Saving to a directory the PHP interpreter processes.

Step 4: Impact narrative​

A web shell is not “just a file”, it is persistent code execution on the server, often leading to data theft, lateral movement, or defacement.

Lab-only: Do not expand beyond proving phpinfo or an agreed harmless callback.

Why this works​

File upload risks combine:

  1. Insufficient validation of true file type (magic bytes) and extension policy.
  2. Executable storage location mapped to the URL space.
  3. Missing antivirus/content scanning for known malware patterns.

Defender notes​

How to detect​

  • Upload logs with unusual extensions (.php, .jsp, .asp) in image folders.
  • New files in web content directories from app users.
  • IDS/EDR alerts on web process spawning shells.

How to prevent​

  1. Store uploads outside the web root; serve via a separate download endpoint that sets Content-Disposition and does not execute.
  2. Verify content with libraries (image re-encode, strip metadata), not only extension checks.
  3. Randomize filenames; forbid executable extensions.
  4. WAF and least privilege for the app pool identity.

Try these variations​

Easy​

  • Upload a real .jpg and confirm it displays, compare response headers to the PHP case.

Medium​

  • At higher DVWA levels, try MIME manipulation and double extensions, document what the server checks.

Hard​

  • Research polyglot files, why re-encoding images server-side helps.

Evidence checklist​

  • Screenshot or log of successful upload of a non-image file type (lab-approved).
  • Proof of execution (phpinfo) or clear documentation of blocking at higher levels.
  • One paragraph: where you would store uploads in a secure redesign.

Next steps​