file-upload

File Upload Detection

Overview

File upload flaws arise when an application accepts a file from a user but does not sufficiently constrain its type, name, contents, or size, and then stores or serves it somewhere that gives the file power it should not have. The flaw sits across three linked points in the request lifecycle: the handler that parses the multipart body or fetches the file, the code that decides the storage path and name, and the configuration that determines how the stored file is later served. The attacker is a remote user, often unauthenticated, who submits a crafted file. In the worst case a file the server will interpret lands in a location the server executes, giving remote code execution and full compromise; short of that, an inline-served document yields stored cross-site scripting against every viewer, a traversal in the name places a file anywhere writable, and an oversized or highly compressible file exhausts resources. This skill finds such flaws by locating every upload and storage site, checking each site in parallel, and merging the results into <output_dir>/file-upload-results.md.

What it is NOT

• Path traversal (/websec:path-traversal): a traversal sequence in an uploaded name is an upload attack technique and belongs here when the fix is to stop deriving the destination from the name. Test: would the file still be dangerous if it landed exactly where the developer intended? If yes, it is an upload flaw; if the whole problem is the destination escaping the directory, that skill may own it and either home is defensible — pick one and say why.
• Server-side request forgery (/websec:ssrf): a "fetch from URL" import is that skill's finding when the flaw is the server reaching an attacker-chosen destination. It is this skill's when the flaw is what happens to the retrieved bytes afterwards. The same endpoint can produce one of each.
• Cross-site scripting (/websec:xss): an uploaded document that runs script in viewers' browsers is stored scripting delivered through upload. Report it here when the missing control is upload-side (type allow-list, disposition, sniffing protection); note it for that skill when the missing control is output encoding elsewhere.
• Operating system command injection (/websec:os-command-injection): an uploaded interpreted file gives command execution, but the flaw is the upload pipeline, not a shell-invoking sink. That skill owns handlers that pass a filename or file contents into a shell command.
• Race conditions (/websec:race-conditions): a non-atomic validate-then-store window is listed here as a variant because it is specific to upload pipelines. A general concurrency flaw in unrelated business state belongs to that skill.
• Deserialization (/websec:deserialization): an uploaded file whose contents are fed to a native object deserializer is that skill's; note the upload as the delivery path.
• Not a finding: an upload that is stored with a server-generated random name, an extension derived from a verified content type, in a location that never executes and is served with a non-interpretable content type plus an attachment disposition and sniffing protection; acceptance of a file alone, with no demonstrated execution, inline serving, traversal, or resource impact; a filename reflected into a success message with no filesystem or output consequence.