Description
This entry has been deprecated because its abstraction was too low-level. See CWE-532.
Modes of Introduction:
Related Weaknesses
Consequences
This entry has been deprecated because its abstraction was too low-level. See CWE-532.
Modes of Introduction:
If an include file source is accessible, the file can contain usernames and passwords, as well as sensitive information pertaining to the application and system.
Modes of Introduction:
– Implementation
Confidentiality: Read Application Data
Phase: Architecture and Design
Description:
Do not store sensitive information in include files.
Phase: Architecture and Design, System Configuration
Description:
Protect include files from being exposed.
Source code on a web server or repository often contains sensitive information and should generally not be accessible to users.
There are situations where it is critical to remove source code from an area or server. For example, obtaining Perl source code on a system allows an attacker to understand the logic of the script and extract extremely useful information such as code bugs or logins and passwords.
Modes of Introduction:
– Implementation
Confidentiality: Read Application Data
Phase: Architecture and Design, System Configuration
Description:
Recommendations include removing this script from the web server and moving it to a location not accessible from the Internet.
A software system that accepts path input in the form of trailing backslash (‘filedir’) without appropriate validation can lead to ambiguous path resolution and allow an attacker to traverse the file system to unintended locations or access arbitrary files.
Modes of Introduction:
– Implementation
Confidentiality, Integrity: Read Files or Directories, Modify Files or Directories
Phase: Implementation
Description:
Inputs should be decoded and canonicalized to the application’s current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
The web application uses persistent cookies, but the cookies contain sensitive information.
Cookies are small bits of data that are sent by the web application but stored locally in the browser. This lets the application use the cookie to pass information between pages and store variable information. The web application controls what information is stored in a cookie and how it is used. Typical types of information stored in cookies are session identifiers, personalization and customization information, and in rare cases even usernames to enable automated logins. There are two different types of cookies: session cookies and persistent cookies. Session cookies just live in the browser’s memory and are not stored anywhere, but persistent cookies are stored on the browser’s hard drive. This can cause security and privacy issues depending on the information stored in the cookie and how it is accessed.
Modes of Introduction:
– Architecture and Design
Confidentiality: Read Application Data
Phase: Architecture and Design
Description:
Do not store sensitive information in persistent cookies.
The product places sensitive information into files or directories that are accessible to actors who are allowed to have access to the files, but not to the sensitive information.
Modes of Introduction:
– Implementation
Confidentiality: Read Files or Directories
Phase: Architecture and Design, Operation, System Configuration
Description:
Do not expose file and directory information to the user.
This entry has been deprecated because its abstraction was too low-level. See CWE-532.
Modes of Introduction: