file-upload-and-ssrf
Skill47 starsChanged 5 months agoMITView on GitHub
Use when testing file-upload handling, server-side request forgery (SSRF), and insecure deserialization — upload bypasses (type/extension/content, polyglots, path traversal), SSRF to cloud metadata and internal services, and unsafe deserialization sinks. On apps you own or are authorized to test.
In this repository15 other files it gives its agents.
- access-control-testingSkill
- active-pentestSkill
- api-security-testingSkill
- authentication-testingSkill
- business-logic-testingSkill
- client-side-exploitationSkill
- injection-testingSkill
- pentest-reportingSkill
- recon-and-osintSkill
- secrets-management-auditSkill
- security-code-auditSkill
- security-hardeningSkill
- security-testingSkill
- threat-modelingSkill
- vulnerability-chainingSkill
The file
We split this skill into the rules it gives an agent
1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 11
serialized objects: All three are "the server processes attacker-supplied data."
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
File Upload, SSRF & Deserialization (FIND/EXPLOIT — server input handling)
Overview
Three high-impact classes that often reach RCE or full cloud compromise and were previously homeless across the references: untrusted files, untrusted URLs, and untrusted serialized objects. All three are "the server processes attacker-supplied data."
Core principle: Anywhere the server fetches, stores+serves, or reconstructs attacker data, ask what else it can be pointed at or made into.
Applies when / Skip when
- Applies when: the app accepts file uploads, fetches user-supplied URLs, or deserializes input — test each of the three independently.
- Skip when: a given feature is absent → that part is N/A (e.g. no uploads → skip the upload section but still test SSRF/deserialization if present).
- If N/A: report which of the three are absent and test only what exists.
⚠️ Authorization
Your own/authorized non-prod. SSRF can reach real internal infra and cloud creds — keep targets to your environment; use benign canaries, don't pivot out of scope.
File upload
| Check | Test |
| Type/extension bypass | shell.php.jpg, double ext, null byte, case, .phtml/.svg/.htaccess |
| Content-type spoof | Real image bytes + script; mismatched Content-Type header |
| Polyglot | File valid as image and script (e.g. GIF/PHP) |
| Path traversal | Filename ../../var/www/shell.php to control where it lands |
| Executable location | Does it land in a web-served, executable dir? |
| Parser attacks | Malicious SVG (XXE/XSS), Office/ZIP (zip-slip, XXE), image lib CVEs |
| Limits | Size/rate limits; decompression bombs |
The kill condition is upload → reachable executable path → execution. If files are stored outside webroot with random names and non-executable, most upload bugs lose their teeth.
SSRF
- Sinks: URL preview/unfurl, webhooks, import-from-URL, PDF/screenshot/image fetch, SSO metadata, file:// handlers, server-side HTTP clients.
- Targets to prove (benign): your collaborator/OOB host, then
127.0.0.1/internal, then cloud metadatahttp://169.254.169.254/latest/meta-data/(AWS),metadata.google.internal(GCP). - Bypasses to test: alternate IP encodings,
[::1], DNS rebinding, redirects,@-tricks, allowlist parsing flaws. - SSRF→cloud-metadata→IAM creds is a top chain to demonstrate (see
vulnerability-chaining).
Insecure deserialization
- Sinks:
pickle.loads,yaml.load, JavareadObject, PHPunserialize, .NETBinaryFormatter, Nodenode-serializeon untrusted input. - Detect: serialized blobs in cookies/params/bodies; tampering changes server behavior.
- Confirm with a benign gadget (OOB ping) — don't run destructive gadget chains.
See references/upload-ssrf-recipes.md for payloads and safe confirmation.
Output
Per finding: sink, payload, evidence (where the file executed / OOB hit / object reconstructed), and reachable impact (RCE, internal access, cloud creds). Usually High–Critical.
Hand-off
Frequently the foothold/pivot in vulnerability-chaining; reproduce via active-pentest; fix via
security-hardening (store outside webroot + validate content + random names; URL allowlist +
block internal ranges + IMDSv2; safe deserialization formats).
Common mistakes
- Checking only the file extension client-side — validate content server-side.
- Declaring "no SSRF" without testing redirects, DNS rebinding, and IP-encoding bypasses.
- Testing SSRF against real internal infra/prod — stay in your environment.
- Treating deserialization as theoretical — it's a common direct path to RCE.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.