CWE-641, Improper Restriction of Names for Files and Other Resources, applies when the product builds a file or resource name from upstream input and does not restrict it, or restricts it badly.
How it happens
A name looks harmless, but it travels. If it contains scripting characters and is later shown on a dynamic page, a script may run in the visitor's browser. If an application parser consumes the resource, a specially crafted name can exploit a flaw inside that parser, potentially running code on the server. The outcome depends on where the name is used.
# Vulnerable: client-supplied name used as-is
path = os.path.join(UPLOAD_DIR, request.files["f"].filename)
request.files["f"].save(path)
# Fixed: server picks the name
import uuid
path = os.path.join(UPLOAD_DIR, uuid.uuid4().hex)
request.files["f"].save(path)
What an attacker gains
The record lists two outcomes: execution of arbitrary code in the context where the resource is used, and a crash of the consumer code, resulting in information leakage or denial of service.
How to find it
The record lists no detection methods and no observed CVEs. Trace every place a name from a request becomes a file name, key, queue name or table name, and every place a stored name is displayed or parsed.
How to fix it
From MITRE:
- Do not allow users to control names of resources used on the server side.
- Perform allowlist input validation at entry points and again before consuming the resources. Reject bad names rather than trying to cleanse them.
- Make sure the technologies consuming the resources are not vulnerable, for example to buffer overflow or format string flaws, in a way that would allow code execution on a malformed name.
A closer look at names as input
Developers usually validate content and trust names. Yet a name is attacker input like any other, and it is stored, logged, displayed and passed to other systems.
MITRE describes two ways it goes wrong. In the browser, a name containing scripting characters can run as script if the page shows the name without encoding it. On the server, a parser that consumes the resource may be vulnerable to a malformed name, with code execution as the extreme case.
The server-generated name is the cleanest answer. Keep the user's original filename only as display metadata, encode it wherever it is shown, and never use it to build a path. If you must accept names, define the accepted pattern narrowly, such as letters, digits and a single dot, and reject everything else instead of stripping characters.
Finally, review the consumers. A resource with a safe name can still reach a vulnerable parser, so keep the libraries that read these files up to date.
Review checklist:
- Where does a name from a request become a path, key or identifier?
- Can the server generate that name instead?
- Where is a stored name displayed, and is it encoded at that point?
- Which libraries parse the resources, and are they current?
The last question is where a dependency scan helps, since parser flaws are often fixed upstream.
Quick check
Reject or cleanse bad names?
Reject. MITRE advises rejecting bad file names rather than trying to cleanse them.
