File Manipulation

The application allows a file to be created, modified, or deleted in an unintended way - through a parameter that influences a file path or filename without adequate validation, letting an attacker affect files outside the intended scope. This overlaps conceptually with path traversal and file-inclusion patterns but is framed around the manipulation outcome (writing or deleting a file) rather than the read/include outcome those categories focus on.

Confirming file manipulation requires knowing the application's specific file-handling logic - which parameters influence which file operations - and testing path-traversal-style payloads against write/delete operations specifically, which needs the write/delete endpoints to already be identified.

Manual testing of any endpoint that accepts a filename or path parameter for a write, rename, or delete operation, using path-traversal-style payloads to test whether the operation can be redirected outside its intended directory.

Tip: These are typically found by testing with unusual encodings, control characters, and format-specific special characters (like a leading = in an exported field) rather than standard injection payloads, since the whole point of this family is that it slips past filters built for the common case.

Real-World Impact

This family covers edge cases in how input is encoded, decoded, or neutralized before use — gaps that don't fit a single named injection category but produce the same underlying failure: input that should have been treated as inert data ends up being interpreted as something structurally meaningful by whatever consumes it downstream. Improper handling of URL/hex encoding can let an encoded payload slip past a filter that only checks the decoded form (or vice versa). Whitespace and escape/control-sequence neutralization gaps let an attacker use characters a filter didn't anticipate to break out of an expected structure.

CSV/formula injection is a distinctive and often-overlooked member of this family: a cell value starting with =, +, -, or @ in an exported CSV file gets interpreted as a live formula the moment a victim opens it in Excel or a similar tool, which can trigger anything from an annoying calculation to a full remote-command-execution chain through Excel's own formula functions (=cmd|'/c calc'!A1-style payloads have been used exactly this way in real disclosed reports).

Because these are edge cases by nature, they're disproportionately likely to slip past a filter that was built and tested against the common, expected input shape rather than the full space of what a determined attacker might try.

Prevention and Secure Design

Preventing File Manipulation takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Decode fully before validating, and validate at the final consuming context. A filter that inspects encoded input can be bypassed by an encoding it doesn't normalize first — decode completely, then validate against what will actually be used.

Prefix-guard exported spreadsheet data explicitly. Any user-controlled value written into a CSV or spreadsheet export that starts with =, +, -, @, or a tab/carriage-return character should be neutralized (typically by prefixing with a single quote) before export, regardless of what the value otherwise contains.

Use the target format's own escaping/encoding library. Don't hand-write escape logic for whitespace, control characters, or special syntax — the standard library for the specific output format handles edge cases a custom implementation is likely to miss.

Test against the full character space, not just common payloads. Boundary and edge-case testing (unusual whitespace, control characters, encoding variants) catches this family more reliably than testing only well-known injection payloads.