CWE Reference

CWE-657: Violation of Secure Design Principles

Official CWE-657 CWE context with Glexia analysis, remediation guidance, related CVEs, and ATT&CK context.

Release 4.20weaknessDraft

Glexia's Take

CWE-657: Violation of Secure Design Principles

Violation of Secure Design Principles represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.

Executive Impact

Other: Other

Developer Pattern

CWE-657 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.

Confidence

high confidence from CWE-657, 4.20.

Official CWE Definition

CWE-657: Violation of Secure Design Principles

The product violates well-established principles for secure design.

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.

Type: weakness
Abstraction: Class
Status: Draft
Source: MITRE CWE definition

Developer And Remediation Guidance

How teams prevent and detect this weakness

Causes

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.
The IPSEC specification is complex, which resulted in bugs, partial implementations, and incompatibilities between vendors.
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.
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.
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.
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]

Remediation

Use safe APIs
Centralize the control
Add regression tests
Review logs and telemetry for attempted abuse

Detection

Code review
SAST
DAST
Focused regression tests

Mappings

Related CVEs, CWEs, and ATT&CK context

Related CWEs

Related CVEs

Related CVE mappings appear after CVE records are cross-indexed.

Open CWE CVE mapping

ATT&CK Relevance

ATT&CK relevance is shown only when reviewed or responsibly inferred.