The J2EE application directly uses sockets instead of using framework method calls.
Modes of Introduction:
– Architecture and Design
Other: Quality Degradation
Phase: Architecture and Design
Description:
Use framework method calls instead of using sockets directly.
This entry has been deprecated because it was a duplicate of CWE-350. All content has been transferred to CWE-350.
Modes of Introduction:
An exception is thrown from a function, but it is not caught.
When an exception is not caught, it may cause the program to crash or expose sensitive information.
Modes of Introduction:
– Implementation
CWE-705
CWE-703
CWE-703
CWE-703
Availability, Confidentiality: DoS: Crash, Exit, or Restart, Read Application Data
An uncaught exception could cause the system to be placed in a state that could lead to a crash, exposure of sensitive information or other unintended behaviors.
This entry has been deprecated because of name
confusion and an accidental combination of multiple
weaknesses. Most of its content has been transferred to
CWE-785.
This entry was deprecated for several reasons. The primary
reason is over-loading of the “path manipulation” term and the
description. The original description for this entry was the
same as that for the “Often Misused: File System” item in the
original Seven Pernicious Kingdoms paper. However, Seven
Pernicious Kingdoms also has a “Path Manipulation” phrase that
is for external control of pathnames (CWE-73), which is a
factor in symbolic link following and path traversal, neither
of which is explicitly mentioned in 7PK. Fortify uses the
phrase “Often Misused: Path Manipulation” for a broader range
of problems, generally for issues related to buffer
management. Given the multiple conflicting uses of this term,
there is a chance that CWE users may have incorrectly mapped
to this entry.
The second reason for deprecation is an implied combination of
multiple weaknesses within buffer-handling functions. The
focus of this entry was generally on the path-conversion
functions and their association with buffer
overflows. However, some of Fortify’s Vulncat entries have the
term “path manipulation” but describe a non-overflow weakness
in which the buffer is not guaranteed to contain the entire
pathname, i.e., there is information truncation (see CWE-222
for a similar concept). A new entry for this non-overflow
weakness may be created in a future version of CWE.
Modes of Introduction:
The software uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize “/../” sequences that can resolve to a location that is outside of that directory.
Modes of Introduction:
– Implementation
Confidentiality, Integrity: Read Files or Directories, Modify Files or Directories
Phase: Implementation
Description:
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 software performs an operation at a privilege level that is higher than the minimum level required, which creates new weaknesses or amplifies the consequences of other weaknesses.
Modes of Introduction:
– Implementation
Likelihood of Exploit: Medium
Confidentiality, Integrity, Availability, Access Control: Gain Privileges or Assume Identity, Execute Unauthorized Code or Commands, Read Application Data, DoS: Crash, Exit, or Restart
An attacker will be able to gain access to any resources that are allowed by the extra privileges. Common results include executing code, disabling services, and reading restricted data.
Phase: Architecture and Design, Operation
Description:
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Phase: Architecture and Design
Description:
Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.
Phase: Architecture and Design
Description:
Identify the functionality that requires additional privileges, such as access to privileged operating system resources. Wrap and centralize this functionality if possible, and isolate the privileged code as much as possible from other code [REF-76]. Raise privileges as late as possible, and drop them as soon as possible to avoid CWE-271. Avoid weaknesses such as CWE-288 and CWE-420 by protecting all possible communication channels that could interact with the privileged code, such as a secondary socket that is only intended to be accessed by administrators.
Phase: Implementation
Description:
Perform extensive input validation for any privileged code that must be exposed to the user and reject anything that does not fit your strict requirements.
Phase: Implementation
Description:
When dropping privileges, ensure that they have been dropped successfully to avoid CWE-273. As protection mechanisms in the environment get stronger, privilege-dropping calls may fail even if it seems like they would always succeed.
Phase: Implementation
Description:
If circumstances force you to run with extra privileges, then determine the minimum access level necessary. First identify the different permissions that the software and its users will need to perform their actions, such as file read and write permissions, network socket permissions, and so forth. Then explicitly allow those actions while denying all else [REF-76]. Perform extensive input validation and canonicalization to minimize the chances of introducing a separate vulnerability. This mitigation is much more prone to error than dropping the privileges in the first place.
Phase: Operation, System Configuration
Description:
Ensure that the software runs properly under the Federal Desktop Core Configuration (FDCC) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.
The software does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.
Two common programmer assumptions are “this function call can never fail” and “it doesn’t matter if this function call fails”. If an attacker can force the function to fail or otherwise return a value that is not expected, then the subsequent program logic could lead to a vulnerability, because the software is not in a state that the programmer assumes. For example, if the program calls a function to drop privileges but does not check the return code to ensure that privileges were successfully dropped, then the program will continue to operate with the higher privileges.
Many functions will return some value about the success of their actions. This will alert the program whether or not to handle any errors caused by that function.
Modes of Introduction:
– Implementation
Likelihood of Exploit: Low
Availability, Integrity: Unexpected State, DoS: Crash, Exit, or Restart
An unexpected return value could place the system in a state that could lead to a crash or other unintended behaviors.
Phase: Implementation
Effectiveness: High
Description:
Check the results of all functions that return a value and verify that the value is expected.
Checking the return value of the function will typically be sufficient, however beware of race conditions (CWE-362) in a concurrent environment.
Phase: Implementation
Description:
Ensure that you account for all possible return values from the function.
Phase: Implementation
Description:
When designing a function, make sure you return a value or throw an exception in case of an error.
The software incorrectly checks a return value from a function, which prevents the software from detecting errors or exceptional conditions.
Important and common functions will return some value about the success of its actions. This will alert the program whether or not to handle any errors caused by that function.
Modes of Introduction:
– Implementation
Likelihood of Exploit: Low
Availability, Integrity: Unexpected State, DoS: Crash, Exit, or Restart
An unexpected return value could place the system in a state that could lead to a crash or other unintended behaviors.
Phase: Architecture and Design
Description:
Use a language or compiler that uses exceptions and requires the catching of those exceptions.
Phase: Implementation
Description:
Properly check all functions which return a value.
Phase: Implementation
Description:
When designing any function make sure you return a value or throw an exception in case of an error.
Storing a password in plaintext may result in a system compromise.
Password management issues occur when a password is stored in plaintext in an application’s properties, configuration file, or memory. Storing a plaintext password in a configuration file allows anyone who can read the file access to the password-protected resource. In some contexts, even storage of a plaintext password in memory is considered a security risk if the password is not cleared immediately after it is used.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: High
Access Control: Gain Privileges or Assume Identity
Phase: Architecture and Design
Description:
Avoid storing passwords in easily accessible locations.
Phase: Architecture and Design
Description:
Consider storing cryptographic hashes of passwords as an alternative to storing in plaintext.
Phase:
Effectiveness: None
Description:
A programmer might attempt to remedy the password management problem by obscuring the password with an encoding function, such as base 64 encoding, but this effort does not adequately protect the password because the encoding can be detected and decoded easily.
The storage of passwords in a recoverable format makes them subject to password reuse attacks by malicious users. In fact, it should be noted that recoverable encrypted passwords provide no significant benefit over plaintext passwords since they are subject not only to reuse by malicious attackers but also by malicious insiders. If a system administrator can recover a password directly, or use a brute force search on the available information, the administrator can use the password on other accounts.
Modes of Introduction:
– Architecture and Design
Likelihood of Exploit: High
Confidentiality, Access Control: Gain Privileges or Assume Identity
User’s passwords may be revealed.
Access Control: Gain Privileges or Assume Identity
Revealed passwords may be reused elsewhere to impersonate the users in question.
Phase: Architecture and Design
Description:
Use strong, non-reversible encryption to protect stored passwords.