Establish upload acceptance, storage and retrieval

Needs: A valid upload request and permitted account; the server accepts and stores controlled bytes

Create and upload a benign canary

# Create and upload a benign canary
printf '%s\n' 'UPLOAD_CANARY_7F31' > probe.txt
curl -sk -b cookies.txt -F 'file=@probe.txt;filename=probe.txt;type=text/plain' http://TARGET:PORT/upload

Record separately: acceptance, server-side name, storage path, retrieval URL, response content type, filesystem write identity and whether the storage location is executable.

Verify → Confirm saved/retrieved bytes and the final identifier/path; a success message alone is insufficient.

If it fails → A rejected extension may be client validation, server MIME/content policy or role permission. Preserve a valid benign baseline before changing one property. More detail ↓

If → then

Uploads are retrievable and the application stack suggests an executable file handler → Execute an uploaded file through a compatible handler
Needs: Controlled executable content survives validation; final storage/URL is handled by the compatible interpreter; process execution is permitted
A multipart filename/import path appears to influence the filesystem destination → Use upload path control to reach a useful consumer
Needs: Destination path control survives normalization; write identity can reach the destination; a known consumer accepts the resulting file
Forms, downloads, exports, account functions or role-specific interfaces → Map functions, roles and normal requests manually
Needs: A normal request baseline and the relevant account/role; authorized accounts for role comparisons

No useful finding → another task in this topic. Failed check → resolve the failure before ruling out the path.

Explanation & examples

Establish upload acceptance, storage and retrieval

USE WHEN: An upload/import/attachment function
STARTING ACCESS: A reproducible application request and a controlled input or access-context comparison
RESULT: A verified write/retrieval primitive with a known server-side identifier

Recognize the clue

Browse normal attachment/import/profile functions and capture one accepted harmless multipart upload with its returned identifier.

printf '%s\n' 'UPLOAD_CANARY' > probe.txt
curl -sk -b cookies.txt -F 'file=@probe.txt;type=text/plain' http://TARGET:PORT/upload

SYNTHETIC EXAMPLE OUTPUT

HTTP/1.1 201 Created
{"id":"UPLOAD_ID","url":"/files/UPLOAD_ID"}

Means: The real upload route, field and response identify a storage/retrieval candidate.

Confirm: Retrieve the canary independently; establish stored bytes, final name and account/context before testing execution.

After validation: The canary is stored and retrievable: a write/retrieval primitive is verified.
Ruled out in this context: The server only validates and discards the upload: reject the assumed persistent-write capability.
Still inconclusive: A success message without a retrieval/path observation leaves persistence unknown.

Troubleshooting: A rejected extension may be client validation, server MIME/content policy or role permission. Preserve a valid benign baseline before changing one property.

Create and upload a benign canary:

Then verify the returned identifier/path and retrieve the bytes.

Record separately: acceptance, server-side name, storage path, retrieval URL, response content type, filesystem write identity and whether the storage location is executable.

Why it works

Accepted upload, stored filename, retrieval route and filesystem location are distinct facts. Server rename and content transformation can change the resulting capability.

Worked example · hypothetical

Observation: upload returns an object ID. Test: retrieve it independently. Illustrative output: the unique canary appears but the filename was changed. Interpretation: write/retrieval is established; investigate actual handling before execution.

New identity, privilege, host or route? Re-enumerate → All topic tasks →

Study guide ↗Full procedure ↗Cheatsheet ↗