CWE-657: Violation of Secure Design Principles
Description
The product violates well-established principles for secure design.
Submission Date :
Jan. 30, 2008, midnight
Modification Date :
2023-10-26 00:00:00+00:00
Organization :
MITRE
Extended Description
This can introduce resultant weaknesses or make it easier for developers to introduce related weaknesses during implementation. Because code is centered around design, it can be resource-intensive to fix design problems.
Example - 1
Switches may revert their functionality to that of hubs when the table used to map ARP information to the switch interface overflows, such as when under a spoofing attack. This results in traffic being broadcast to an eavesdropper, instead of being sent only on the relevant switch interface. To mitigate this type of problem, the developer could limit the number of ARP entries that can be recorded for a given switch interface, while other interfaces may keep functioning normally. Configuration options can be provided on the appropriate actions to be taken in case of a detected failure, but safe defaults should be used.
Example - 2
The IPSEC specification is complex, which resulted in bugs, partial implementations, and incompatibilities between vendors.
Example - 3
When executable library files are used on web servers, which is common in PHP applications, the developer might perform an access check in any user-facing executable, and omit the access check from the library file itself. By directly requesting the library file (CWE-425), an attacker can bypass this access check.
Example - 4
Single sign-on technology is intended to make it easier for users to access multiple resources or domains without having to authenticate each time. While this is highly convenient for the user and attempts to address problems with psychological acceptability, it also means that a compromise of a user's credentials can provide immediate access to all other resources or domains.
Example - 5
The design of TCP relies on the secrecy of Initial Sequence Numbers (ISNs), as originally covered in CVE-1999-0077 [REF-542]. If ISNs can be guessed (due to predictability, CWE-330) or sniffed (due to lack of encryption during transmission, CWE-312), then an attacker can hijack or spoof connections. Many TCP implementations have had variations of this problem over the years, including CVE-2004-0641, CVE-2002-1463, CVE-2001-0751, CVE-2001-0328, CVE-2001-0288, CVE-2001-0163, CVE-2001-0162, CVE-2000-0916, and CVE-2000-0328.
Example - 6
The "SweynTooth" vulnerabilities in Bluetooth Low Energy (BLE) software development kits (SDK) were found to affect multiple Bluetooth System-on-Chip (SoC) manufacturers. These SoCs were used by many products such as medical devices, Smart Home devices, wearables, and other IoT devices. [REF-1314] [REF-1315]
Related Weaknesses
This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined to give an overview of the different insight to similar items that may exist at higher and lower levels of abstraction.
CWE-250: Execution with Unnecessary Privileges
CWE-636: Not Failing Securely ('Failing Open')
CWE-637: Unnecessary Complexity in Protection Mechanism (Not Using 'Economy of Mechanism')
CWE-638: Not Using Complete Mediation
CWE-653: Improper Isolation or Compartmentalization
CWE-654: Reliance on a Single Factor in a Security Decision
CWE-655: Insufficient Psychological Acceptability
CWE-656: Reliance on Security Through Obscurity
CWE-671: Lack of Administrator Control over Security
CWE-710: Improper Adherence to Coding Standards
CWE-1192: System-on-Chip (SoC) Using Components without Unique, Immutable Identifiers
CWE-1395: Dependency on Vulnerable Third-Party Component
Visit http://cwe.mitre.org/ for more details.