auditing-file-upload-and-content-handling

name	auditing-file-upload-and-content-handling
description	Audit a file-upload and content-handling path for an attacker-supplied file whose bytes, declared type, name, or embedded content reach a sink that stores it in a served or executable location or feeds it to a parser that acts on its content, after the type-decision layer and the serve behavior are resolved. Covers an extension or content-type trusted for a type decision that a second layer contradicts, an SVG, HTML, or XML file stored and served inline as active content, image or document parser exploitation, a polyglot file passing one content check yet executing in another context, an upload path writing outside the intended directory, and an archive expanding to a write primitive. Use when reviewing upload validation, storage, and serving, not the client-side DOM sink or the archive-extraction write primitive their own skills own. An uploaded file is the source, a serve or parse sink acting on its content is the sink, and a type decision one layer contradicts is the bug.
license	MIT

Auditing file upload and content handling: when the type one layer trusts another layer contradicts

A file upload becomes a vulnerability when the layer that decides a file's type disagrees with the layer that later serves or parses it. The upload validator trusts the extension or the declared content-type; the web server sniffs the bytes, or the storage path serves it inline, or a parser acts on embedded content, and the two disagreements meet in the attacker's favor. You audit it by resolving how the type is decided at upload and how the file is served and parsed afterward, then finding where those two views diverge. The strongest false-positive killers live in the serve layer: a no-execute sandboxed origin with a forced download, or a server-side re-encode, neutralizes the content regardless of its bytes. The client-side DOM sink and the archive-extraction write primitive have their own skills; this skill owns the upload-to-serve-or-parse decision.

When to use

• You are reviewing an upload endpoint, its type validation, where files are stored, and how they are served.
• A file's bytes, declared type, name, or embedded content reach a parser, a renderer, or a served location.
• You want to know whether an uploaded file executes or is parsed dangerously somewhere downstream.

Scope check

Audit only applications you own or are authorized to assess, and upload a crafted file only to a system in scope, a stored active file can execute against real users. Adjudicate on the validation, the storage, and the serve path. If you can't name the authorization, stop.

The loop

1. Resolve the type-decision layer and the serve behavior first. Determine how the upload decides the file's type (an extension check, a declared content-type, a magic-byte sniff, or a combination) and how the file is served afterward (inline or as an attachment, from the app origin or a separate no-execute origin, with what content-type). The bug is a divergence between these two, so establish both before judging any single check.

2. Check the type-decision contradiction. Look for an extension or a client-declared content-type trusted for the type decision while a second layer (the web server's own sniffing, a content-disposition header, or the storage path's handler) treats the file differently, so a double extension, a null-byte or case trick, or an appended-data file is stored as one type and served as another.

3. Check active-content serving. Look for an SVG, HTML, or XML file stored and served inline as active content, giving a stored cross-site-scripting or an external-entity parse, when it should be served as an inert attachment or sanitized.

4. Check parser exploitation. Look for an uploaded image or document fed to a parser or converter that acts on its embedded content (a delegate command, an external reference, an embedded script), turning a crafted file into code execution or a server-side request in the parser.

5. Check polyglots, path, and archives. Look for a polyglot file that passes one content check yet executes in another context, an upload path that writes outside the intended directory (traversal in the filename), and an archive uploaded and expanded to a write primitive (hand the extraction internals to the archive-extraction skill, keep the upload framing here).

6. Confirm and record. Confirm by uploading a crafted file and showing it is stored and then executed or parsed dangerously along the reachable path. Kill the lead if the file is served from a no-execute separate origin with a forced attachment disposition and a fixed non-active content-type so the execution path is cut regardless of the bytes, if the server re-encodes the file (an image recompressed through a hardened pipeline) stripping any polyglot or parser payload, if the type is decided by a magic-byte allowlist and the extension and the serve layer all agree, if the stored filename is randomized and the path is outside the web root so a direct request cannot execute it, if the parser is hardened (delegates and external entities disabled) so the crafted content is inert, or if an SVG is sanitized or served with a policy that blocks inline script. Record the upload, the type divergence, and the serve or parse sink.

Where content handling leaks

• The bug is a divergence, not a single check. The upload validator and the serve or parse layer holding different views of the file's type is the vulnerability; one layer alone rarely tells you.
• The serve layer is the strongest killer. A no-execute sandboxed origin with a forced download, or a fixed inert content-type, neutralizes the file whatever its bytes; resolve the serve behavior first.
• Re-encoding strips payloads. Recompressing an image through a hardened pipeline destroys polyglot and parser content; a validated-then-stored-verbatim file does not.
• Active content served inline is stored injection. An SVG, HTML, or XML served inline runs or parses; the same file forced as an attachment from a sandbox origin does not.
• The parser is a sink too. An image or document converter that acts on embedded delegates or external references is code execution or a server-side request; hardening the parser closes it.

Worked example (a confirm and a kill)

Confirm. An avatar upload validates only the file extension, stores the file under the application's web root with its original name, and the server serves it with a sniffable content-type. An attacker uploads an SVG (named to pass the extension check) containing a script; fetching the stored file executes the script in the application origin. Confirmed stored cross-site-scripting through an upload validated by extension and served inline as active content, high, remediation = serve user uploads as inert attachments from a separate no-execute origin, decide type by magic bytes, and sanitize or re-encode.

Kill. The same upload re-encodes the image to a fixed format through a hardened pipeline, stores it under a randomized name outside the web root, and serves it from a separate user-content origin with a forced attachment disposition and a fixed non-active content-type. The crafted bytes do not survive the re-encode and the file cannot execute where it is served. Killed, kill_reason = "the file is re-encoded and served no-execute cross-origin with a forced download, so the content-handling sink is neutralized regardless of the uploaded bytes."

Rationalizations to reject

• "We check the extension." -> Does the serve layer agree? A double extension or a sniffed type diverges from the extension; the contradiction between the layers is the bug.
• "It is just an image." -> Served inline from the app origin, or re-encoded and served as an attachment from a sandbox origin? An SVG or a polyglot served inline is active content.
• "The parser is standard." -> Are its delegates and external entities disabled? A converter that acts on embedded content is a code-execution or server-side-request sink.
• "The filename is validated." -> Against traversal, and stored where? A traversal in the name or a web-root path lets a direct request reach the file.
• "It is a zip we extract." -> The extraction write primitive is the archive-extraction skill's; here confirm the upload accepts and routes it, and hand the expansion there.

Executing this in practice

You need the upload endpoint and its type validation, whether the file is re-encoded, where it is stored (web root or not, original or randomized name), how it is served (inline or attachment, which origin, which content-type), and any parser or converter the content reaches. For each upload, decide whether the type-decision layer and the serve or parse layer diverge in the attacker's favor. Reading the validator tells you what is accepted; reading the serve path tells you what happens to it.

Related

• hunting-unsafe-archive-extraction - owns the archive-expansion write primitive (path traversal and resource exhaustion on extract); this skill routes an uploaded archive there rather than duplicating it.
• testing-client-side-dom-vulnerabilities - owns the client-side DOM sink taxonomy; the SVG-as-active- content shape here is the server-served, stored variant, framed as content handling rather than a DOM sink.
• reviewing-content-security-policy - the policy that blocks inline script in served active content is a mitigating layer this skill checks when adjudicating an SVG or HTML upload.
• FINDING-SCHEMA.md - source = an uploaded file, sink = a serve or parse operation acting on its content, evidence = the type-decision layer, the serve behavior, and the divergence between them.