CWE-668 describes a product that exposes a resource to the wrong control sphere, giving unintended actors inappropriate access to it. It is a broad class and a very common one. Insecure file permissions, path handling that reaches the wrong file, and data placed where anyone can read it all fit here. Every application that stores or serves resources is exposed.
How it happens
MITRE explains the idea with files. A program may intend that private files are available only to a specific user. That defines a control sphere meant to keep everyone else out. If the permissions are insecure, other parties can read those files.
A second sphere may limit a user to private files and nothing else on the system. If the program does not make sure the user is only requesting private files, the user might reach other files. In both cases, a resource ends up exposed to the wrong party.
MITRE describes two ways it goes wrong: resources are inadvertently exposed through mechanisms like insecure permissions, or a program accidentally operates on the wrong object.
# Vulnerable: the user picks the file name, so they can pick any file
@app.route("/download")
def download():
name = request.args["name"]
return send_file("/srv/data/" + name) # "../../etc/passwd" and friends
# Safer: resolve the path and confirm it stays inside the allowed folder
import os
BASE = os.path.realpath("/srv/data")
@app.route("/download")
def download():
path = os.path.realpath(os.path.join(BASE, request.args["name"]))
if os.path.commonpath([BASE, path]) != BASE:
abort(403)
return send_file(path)
File permissions follow the same logic. A file written with world-readable permissions puts private data into the sphere of every local user.
What an attacker gains
MITRE lists three consequences.
- Confidentiality, rated high. An adversary who reaches the resource may retrieve private data.
- Integrity, rated medium. An adversary may modify data in the resource, causing the system that relies on it to make unintended decisions.
- Other, varying by context. The effect depends on how the product uses the resource.
How to find it
The record lists no detection methods. A practical way to test is to write down every sphere in your design: who should reach each resource, and from where. Then check each boundary from the outside.
- Request resources as an unauthenticated user, as a low-privilege user, and as a user from a different tenant.
- List file permissions on everything the application writes, and look for anything broader than needed.
- Review every place a user-supplied value picks a file, object or record.
- Look at storage buckets, shares, temp directories and log files for unintended readers.
A dynamic web scan helps find the externally visible cases quickly, and the demo below shows the flow.
How to fix it
MITRE lists no formal mitigations on this entry. The guidance below follows from its description.
- Define the intended sphere for each resource in writing.
- Set the narrowest permissions that work, and set them at creation time, not after.
- Never build a file path or object key directly from user input. Resolve it and verify it stays inside the allowed area.
- Check authorization on the object itself, not just on the route that leads to it.
- Keep private and public resources in separate locations.
- Retest after changes, since permissions drift.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
What is a control sphere?
The set of actors who are meant to have access to a resource. Exposure to the wrong sphere means someone outside that set can reach it.
Name two ways this happens, per MITRE.
Insecure permissions on a resource, and a program operating on the wrong object, such as a file the user was never meant to request.
Which consequence does MITRE rate highest?
Confidentiality, rated high, followed by integrity at medium.
