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
Lab-only variant — controlled SSH public-key placement
# Lab-only variant — controlled SSH public-key placement
ssh-keygen -t ed25519 -f ./web_upload_key -N ''
cp ./web_upload_key.pub ./authorized_keys
curl -sk -b cookies.txt -F 'file=@authorized_keys;filename=../../../../home/USER/.ssh/authorized_keys' http://TARGET:PORT/upload
ssh -i ./web_upload_key -p SSH_PORT USER@TARGET
Use only in a disposable authorized lab after confirming the exact user/home, SSH service, web write identity, destination semantics and overwrite impact. Failure can mean path normalization, permission denial, SSH policy or a different user—not necessarily that upload path control is absent.
Verify → Independently prove destination and bytes before claiming a privileged consumer or accepted key.
If it fails → Normalization, permissions and consumer policy are separate failure points; preserve the proven write without overstating its effect. More detail ↓
Explanation & examples
Use upload path control to reach a useful consumer
- USE WHEN
- A multipart filename/import path appears to influence the filesystem destination
- STARTING ACCESS
- A reproducible application request and a controlled input or access-context comparison
- RESULT
- A verified destination write and, when separately enabled, an authentication or execution transition
Recognize the clue
Inspect an accepted upload's raw multipart filename/path fields and compare the returned destination for one harmless unique filename.
curl -sk -b cookies.txt -F 'file=@probe.txt;filename=../UNIQUE_CANARY.txt;type=text/plain' http://TARGET:PORT/upload
Submitted filename: ../UNIQUE_CANARY.txt
Independent listing: /EXPECTED_PARENT/UNIQUE_CANARY.txtMeans: An independently located out-of-directory canary is path-control evidence; it does not establish access to another user's key directory.
Confirm: Confirm filesystem identity, exact destination semantics, write permissions and a useful consumer/trigger.
- After validation
- A controlled usable destination and its consumer accept the file: select that verified write-to-access chain.
- Ruled out in this context
- The server strips path components and stores only a generated basename: reject arbitrary placement in that context.
- Still inconclusive
- A reflected submitted path without independent location evidence leaves placement inconclusive.
Troubleshooting: Normalization, permissions and consumer policy are separate failure points; preserve the proven write without overstating its effect.
First use a harmless unique filename outside the normal upload directory and verify it through a separate read/listing primitive. Do not overwrite an existing file as a detection test.
Lab-only variant — controlled SSH public-key placement
Use only in a disposable authorized lab after confirming the exact user/home, SSH service, web write identity, destination semantics and overwrite impact. Failure can mean path normalization, permission denial, SSH policy or a different user—not necessarily that upload path control is absent.
Why it works
Arbitrary placement is different from an executable web upload. An SSH-key route additionally requires the exact user/home, directory/file semantics, accepted key policy and reachable SSH service.
Worked example · hypothetical
Observation: an upload stores a benign canary outside its normal directory. Test: independently locate/read it. Illustrative output: the destination belongs to the web identity but another user's SSH directory is not writable. Interpretation: path control exists; the proposed key-placement chain does not.
New identity, privilege, host or route? Re-enumerate → All topic tasks →