logo

Files or Directories Accessible to External Parties

Draft Base
Structure: Simple
Description

The product makes files or directories accessible to unauthorized actors, even though they should not be.

Extended 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.

Common Consequences 1
Scope: ConfidentialityIntegrity

Impact: Read Files or DirectoriesModify Files or Directories
Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Potential Mitigations 1
Phase: ImplementationSystem ConfigurationOperation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to disable public access.
Demonstrative Examples 2

ID : DX-160

The following Azure command updates the settings for a storage account:

Code Example:

Bad
Shell
shell
However, "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.

Code Example:

Good
Shell
shell

ID : DX-161

The following Google Cloud Storage command gets the settings for a storage account named 'BUCKET_NAME':

Code Example:

Informative
Shell
shell
Suppose the command returns the following result:

Code Example:

Bad
JSON

{

json
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:

Code Example:

Good
Shell

gsutil iam ch -d allUsers gs://BUCKET_NAME gsutil iam ch -d allAuthenticatedUsers gs://BUCKET_NAME
Observed Examples 1
CVE-2005-1835Data file under web root.
References 2
CIS Microsoft Azure Foundations Benchmark version 1.5.0
Center for Internet Security
16-08-2022
https://www.cisecurity.org/benchmark/azure(2023-01-19)
ID: REF-1307
CIS Google Cloud Computing Platform Benchmark version 1.3.0
Center for Internet Security
31-03-2022
https://www.cisecurity.org/benchmark/google_cloud_computing_platform(2023-04-24)
ID: REF-1327
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Technologies:
Not Technology-Specific : UndeterminedCloud Computing : Often
Modes of Introduction
Architecture and Design
Implementation
Operation
Related Attack Patterns
Affected Resources
  1. File or Directory
Related Weaknesses
ChildOf: Exposure of Resource to Wrong Sphere (CWE-668)
ChildOf: Exposure of Resource to Wrong Sphere (CWE-668)
ChildOf: Improper Authorization (CWE-285)
Taxonomy Mapping
  • OWASP Top Ten 2004
  • CERT C Secure Coding