🧠 Introduction

Sometimes, the most critical vulnerabilities are not caused by complex logic… but by small inconsistencies in how input is handled.

In this write-up, I'll walk through a vulnerability in a file access system that uses HMAC-based presigned URLs, and how a subtle mismatch between validation and sanitization leads to arbitrary file access.

⚙️ Application Logic Overview

The application exposes two main functionalities:

  • action=sign → Generates a signed URL for a file
  • action=download → Downloads the file using the signed URL

Security Controls

  • Only files under the public/ directory are allowed
  • Path traversal (..) is explicitly blocked

At first glance, everything looks secure.

🚨 The Vulnerability

The issue lies in an inconsistent handling of the filename between two stages:

🔹 During Signing

  • The application:
  1. Checks if the filename contains ..
  2. Then applies sanitization via sanitizeFilename()

🔹 During Download

  • ❌ No sanitization is applied
  • The filename is used directly

💣 Exploit Strategy

The idea is simple:

Make the server validate a "safe" input… that becomes "dangerous" after sanitization.

🧪 Step-by-Step Exploitation

🔹 Step 1 — Bypass the .. Filter

Instead of using:

../

We inject a control character between the dots:

.%7f.

Resulting payload:

public/.%7f./super_secret.txt

✔ The server does NOT detect ..

✔ The validation passes

🔹 Step 2 — Sanitization Effect

The function: sanitizeFilename()

removes control characters. So: .%7f. → ..

Final transformed path: public/../super_secret.txt

🔹 Step 3 — Generate a Valid Signature

Request:

?action=sign&filename=public/.%7f./super_secret.txt

The server generates the signature based on:

public/../super_secret.txt

🔹 Step 4 — Retrieve the File

Now we use the normalized path:

?action=download&filename=public/../super_secret.txt&expires=…&signature=…

Resolved path:

files/public/../super_secret.txt → files/super_secret.txt

✔ Signature matches ✔ Access control bypassed ✔ Sensitive file retrieved

📊 Impact

  • Unauthorized access to restricted files
  • Complete bypass of access control
  • High-risk sensitive data exposure

This vulnerability effectively allows an attacker to read any file accessible via path traversal.

🧨 Root Cause

The root issue is:

❌ Validation is performed before sanitization

This creates a gap where input can change after validation.

🛡️ Remediation

✔️ Correct Approach

  1. Apply sanitization before validation
  2. Ensure consistent input handling across all flows

✔️ Additional Protections

🔒 Reject control characters

if (preg_match('/[\x00-\x1F\x7F]/', $filename)) { reject(); }

🔒 Enforce strict allowlist

^public/[a-zA-Z0–9._-]+$

🔒 Normalize paths securely

  • Use realpath()
  • Ensure the resolved path stays within the allowed directory

🔒 Use consistent logic

  • The same normalized input must be used in:
  • Signing
  • Verification

🧩 Key Takeaways

  • ⚠️ Order of operations matters in security
  • 🧠 Sanitization ≠ Validation
  • 🔍 Always normalize input before applying checks
  • 💡 Control characters can be used as powerful bypass techniques

🏁 Conclusion

This vulnerability highlights how a small inconsistency in input handling can completely break a security mechanism.

Even when strong cryptographic protections like HMAC are used, logic flaws can render them useless.