Files or Directories Accessible to External Parties
The product makes files or directories accessible to unauthorized actors, even though they should not be.
Description
Web servers, FTP servers, and similar servers may store a set of files underneath a "root" directory that is accessible to the server's users. Applications may store sensitive files underneath this root without also using access control to limit which users may request those files, if any. Alternately, an application might package multiple files or directories into an archive file (e.g., ZIP or tar), but the application might not exclude sensitive files that are underneath those directories.
In cloud technologies and containers, this weakness might present itself in the form of misconfigured storage accounts that can be read or written by a public or anonymous user.
Demonstrations
The following examples help to illustrate the nature of this weakness and describe methods or techniques which can be used to mitigate the risk.
Note that the examples here are by no means exhaustive and any given weakness may have many subtle varieties, each of which may require different detection methods or runtime controls.
Example One
The following Azure command updates the settings for a storage account:
az storage account update --name <storage-account> --resource-group <resource-group> --allow-blob-public-access trueHowever, "Allow Blob Public Access" is set to true, meaning that anonymous/public users can access blobs.
The command could be modified to disable "Allow Blob Public Access" by setting it to false.
az storage account update --name <storage-account> --resource-group <resource-group> --allow-blob-public-access falseExample Two
The following Google Cloud Storage command gets the settings for a storage account named 'BUCKET_NAME':
gsutil iam get gs://BUCKET_NAMESuppose the command returns the following result:
{
"bindings":[{
"members":[
"projectEditor: PROJECT-ID",
"projectOwner: PROJECT-ID"
],
"role":"roles/storage.legacyBucketOwner"
},
{
"members":[
"allUsers",
"projectViewer: PROJECT-ID"
],
"role":"roles/storage.legacyBucketReader"
}
]
}This result includes the "allUsers" or IAM role added as members, causing this policy configuration to allow public access to cloud storage resources. There would be a similar concern if "allAuthenticatedUsers" was present.
The command could be modified to remove "allUsers" and/or "allAuthenticatedUsers" as follows:
gsutil iam ch -d allUsers gs://BUCKET_NAME
gsutil iam ch -d allAuthenticatedUsers gs://BUCKET_NAMESee Also
Weaknesses in this category are related to exposed resource.
Weaknesses in this category are related to the A01 category "Broken Access Control" in the OWASP Top Ten 2021.
Weaknesses in this category are related to authorization components of a system. Frequently these deal with the ability to enforce that agents have the required permis...
This view (slice) covers all the elements in CWE.
This view (slice) lists weaknesses that can be introduced during implementation.
This view (slice) lists weaknesses that can be introduced during design.
Common Weakness Enumeration content on this website is copyright of The MITRE Corporation unless otherwise specified. Use of the Common Weakness Enumeration and the associated references on this website are subject to the Terms of Use as specified by The MITRE Corporation.