File Upload Vulnerabilities and Mitigation Strategies
The article explains how attackers can exploit file upload functionality by uploading malicious files, crafted filenames, SVG payloads, or symlinks to achieve remote code execution, data theft, or server denial‑of‑service, and provides practical defense measures such as whitelist validation, content‑type checks, and upload rate limiting.
File upload vulnerabilities occur when an attacker uploads a malicious executable file to a server that does not properly validate or handle the file, potentially allowing the server to execute the uploaded file and create security breaches.
The filename itself can be abused; attackers may use path traversal strings like ../../../attack.jpg or target critical system files such as /etc/passwd, which, if used directly by the application, can overwrite or read sensitive data.
Below is an example of a raw HTTP multipart request that demonstrates how an attacker can specify a crafted filename:
POST /upload HTTP/1.1
Host: test.com
Connection: keep-alive
Content-Length: 4237161
Accept: */*
Origin: http://test.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.100 Safari/537.36
Content-Type: multipart/form-data; boundary=--WebKitFormBoundary9pQqgBGwpDfftP8l
--WebKitFormBoundary9pQqgBGwpDfftP8l
Content-Disposition: form-data; name="file"; filename="../../attack.jpg"
Content-Type: image/jpeg
...file data...
--WebKitFormBoundary9pQqgBGwpDfftP8l--Even though Node.js may seem less prone to server‑side execution than PHP, client‑side execution risks remain. Uploading HTML files can enable CSRF‑based XSS attacks, and allowing SVG uploads introduces the possibility of embedding malicious tags such as <script>, <style>, or <html> inside the SVG.
Example of a malicious SVG payload:
<svg viewBox="0 0 100 100" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<script>alert(111)</script>
<rect x="25" y="25" width="50" height="50"/>
</svg>Soft links (symlinks) are also files that point to other paths; if an attacker uploads a symlink targeting /etc/passwd, the application may inadvertently read sensitive system files.
Another risk is disk exhaustion: unrestricted or frequent file uploads can fill the server’s storage, causing denial‑of‑service.
Mitigation measures include:
Whitelist or sanitize uploaded filenames and avoid using user‑provided names directly.
Validate file contents using robust methods (e.g., checking magic numbers) rather than relying on file extensions or the Content‑Type header; libraries such as file-type can help.
If allowing .svg uploads, parse the SVG and strip dangerous tags like <script> and <foreignObject>, preferably using a strict whitelist.
For uploaded archives, scan both the archive and its extracted contents using the same validation rules.
Limit upload frequency and monitor disk usage; consider using external storage services to offload files.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
360 Tech Engineering
Official tech channel of 360, building the most professional technology aggregation platform for the brand.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.