Kingdom: API Abuse

An API is a contract between a caller and a callee. The most common forms of API abuse are caused by the caller failing to honor its end of this contract. For example, if a program fails to call chdir() after calling chroot(), it violates the contract that specifies how to change the active root directory in a secure fashion. Another good example of library abuse is expecting the callee to return trustworthy DNS information to the caller. In this case, the caller abuses the callee API by making certain assumptions about its behavior (that the return value can be used for authentication purposes). One can also violate the caller-callee contract from the other side. For example, if a coder subclasses SecureRandom and returns a non-random value, the contract is violated.

94 items found
Weaknesses
Abstract
Do not use VirtualLock to lock pages that contain sensitive data. The function is not always implemented.
Explanation
Heap inspection vulnerabilities occur when sensitive data, such as a password or an encryption key, can be exposed to an attacker because they are not removed from memory.

The VirtualLock function is intended to lock pages in memory to prevent them from being paged to disk. However, on Windows 95/98/ME the function is implemented as stub only and has no effect.

References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 591
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001090, CCI-001199
[3] Standards Mapping - FIPS200 MP
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-4 Information in Shared Resources (P1), SC-28 Protection of Information at Rest (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-4 Information in Shared System Resources, SC-28 Protection of Information at Rest
[7] Standards Mapping - OWASP Mobile 2014 M4 Unintended Data Leakage
[8] Standards Mapping - OWASP Mobile 2024 M6 Inadequate Privacy Controls
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[10] Standards Mapping - OWASP Top 10 2004 A8 Insecure Storage
[11] Standards Mapping - OWASP Top 10 2007 A8 Insecure Cryptographic Storage
[12] Standards Mapping - OWASP Top 10 2010 A7 Insecure Cryptographic Storage
[13] Standards Mapping - OWASP Top 10 2013 A6 Sensitive Data Exposure
[14] Standards Mapping - OWASP Top 10 2017 A3 Sensitive Data Exposure
[15] Standards Mapping - OWASP Top 10 2021 A05 Security Misconfiguration
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 3.4, Requirement 6.5.8, Requirement 8.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 3.4, Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 3.4, Requirement 6.5.3, Requirement 8.2.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 3.5.1, Requirement 6.2.4, Requirement 8.3.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 3.3.2, Requirement 3.3.3, Requirement 3.5.1, Requirement 6.2.4, Requirement 8.3.1
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 3.5 - Sensitive Data Retention, Control Objective 6.3 - Sensitive Data Protection, Control Objective 7 - Use of Cryptography
[28] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3230.2 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3230.2 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3230.2 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3230.2 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3230.2 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3230.2 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3230.2 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002330 CAT II, APSC-DV-002380 CAT II
[50] Standards Mapping - Web Application Security Consortium Version 2.00 Information Leakage (WASC-13)
[51] Standards Mapping - Web Application Security Consortium 24 + 2 Information Leakage
desc.semantic.cpp.heap_inspection_swappable_memory
Abstract
The class is annotated as immutable, but a field is mutated.
Explanation
This class has been annotated with the annotation Immutable, from the JCIP annotations package. However, one of the mutable fields of the class had a mutating method called on it outside of the constructor and destructor.

Example 1: The following code for an immutable final class declares a Set private and final, then mistakenly creates a method that mutates the Set.


@Immutable
public final class ThreeStooges {
private final Set stooges = new HashSet>();
...

public void addStooge(String name) {
stooges.add(name);
}
...
}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] MUTABLE-1: Prefer immutability for value types Oracle
[4] Standards Mapping - Common Weakness Enumeration CWE ID 471
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_field_mutation
Abstract
The class is annotated as immutable, but a field is not final.
Explanation
This class has been annotated with the annotation Immutable, from the JCIP annotations package. A non-final field violates the immutability of the class by allowing the value to be changed.

Example 1: The following code for an immutable class mistakenly declares a field public and not final.


@Immutable
public class ImmutableInteger {
public int value;

}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] OBJ58-J. Limit the extensibility of classes and methods with invariants CERT
[4] MUTABLE-1: Prefer immutability for value types Oracle
[5] Standards Mapping - Common Weakness Enumeration CWE ID 471
[6] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[18] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_non_final_fields
Abstract
The class is annotated as immutable, but a field is mutated.
Explanation
This class has been annotated with the annotation Immutable, from the JCIP annotations package. A public field of a mutable type allows code external to the class to modify the contents and violate the immutability of the class.

Example 1: The following code for an immutable final class mistakenly declares a Set public and final.


@Immutable
public final class ThreeStooges {
public final Set stooges = new HashSet();
...
}
References
[1] B. Goetz Java Concurrency in Practice. Chapter 3: Sharing Objects Guidelines
[2] Package net.jcip.annotations Specification
[3] MUTABLE-1: Prefer immutability for value types Oracle
[4] Standards Mapping - Common Weakness Enumeration CWE ID 471
[5] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[8] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[9] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[10] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[11] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[13] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[14] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[15] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[16] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control
[17] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
desc.structural.java.immutable_public_mutable_fields
Abstract
The J2EE standard forbids the direct management of connections.
Explanation
The J2EE standard requires that applications use the container's resource management facilities to obtain connections to resources.

For example, a J2EE application should obtain a database connection as follows:


ctx = new InitialContext();
datasource = (DataSource)ctx.lookup(DB_DATASRC_REF);
conn = datasource.getConnection();


and should avoid obtaining a connection in this way:


conn = DriverManager.getConnection(CONNECT_STRING);


Every major web application container provides pooled database connection management as part of its resource management framework. Duplicating this functionality in an application is difficult and error prone, which is part of the reason it is forbidden under the J2EE standard.
References
[1] Java 2 Platform Enterprise Edition Specification, v1.4 Sun Microsystems
[2] Standards Mapping - Common Weakness Enumeration CWE ID 245
desc.semantic.java.j2ee_badpractices_getconnection
Abstract
Socket-based communication in web applications is prone to error.
Explanation
The J2EE standard permits the use of sockets only for the purpose of communication with legacy systems when no higher-level protocol is available. Authoring your own communication protocol requires wrestling with difficult security issues, including:

- In-band versus out-of-band signaling

- Compatibility between protocol versions

- Channel security

- Error handling

- Network constraints (firewalls)

- Session management

Without significant scrutiny by a security expert, chances are good that a custom communication protocol will suffer from security problems.

Many of the same issues apply to a custom implementation of a standard protocol. While there are usually more resources available that address security concerns related to implementing a standard protocol, these resources are also available to attackers.
References
[1] Java 2 Platform Enterprise Edition Specification, v1.4 Sun Microsystems
[2] Standards Mapping - Common Weakness Enumeration CWE ID 246
[3] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
desc.semantic.java.j2ee_badpractices_sockets
Abstract
An etcd instance accepts TLS connections from clients that use self-signed certificates.
Explanation
Kubernetes keeps sensitive data in an etcd cluster. Therefore, every etcd instance should only accept connections from authenticated and authorized clients and reject any client that uses a self-signed certificate for TLS connections.

Example 1: The following configuration starts an etcd instance and sets the --auto-tls flag to true. As a result, the etcd instance uses self-signed certificates for TLS connections with clients.

...
spec:
containers:
- command:
...
- etcd
...
- --auto-tls=true
...
References
[1] Operating etcd clusters for Kubernetes The Kubernetes Authors
[2] etcd configuration etcd Authors
[3] Standards Mapping - CIS Kubernetes Benchmark Recommendation 2.3
[4] Standards Mapping - Common Weakness Enumeration CWE ID 296
[5] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287, [25] CWE ID 295
[6] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287
[7] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287
[8] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287
[9] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000166, CCI-000185, CCI-001941, CCI-001942
[11] Standards Mapping - FIPS200 CM
[12] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection
[13] Standards Mapping - NIST Special Publication 800-53 Revision 4 AU-10 Non-Repudiation (P2), IA-2 Identification and Authentication (Organizational Users) (P1), IA-5 Authenticator Management (P1), SC-17 Public Key Infrastructure Certificates (P1)
[14] Standards Mapping - NIST Special Publication 800-53 Revision 5 AU-10 Non-Repudiation, IA-2 Identification and Authentication (Organizational Users), IA-5 Authenticator Management, SC-17 Public Key Infrastructure Certificates
[15] Standards Mapping - OWASP API 2023 API8 Security Misconfiguration
[16] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.6.3 Look-up Secret Verifier Requirements (L2 L3), 2.7.1 Out of Band Verifier Requirements (L1 L2 L3), 2.7.2 Out of Band Verifier Requirements (L1 L2 L3), 2.7.3 Out of Band Verifier Requirements (L1 L2 L3), 2.8.4 Single or Multi Factor One Time Verifier Requirements (L2 L3), 2.8.5 Single or Multi Factor One Time Verifier Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 6.2.1 Algorithms (L1 L2 L3), 9.2.1 Server Communications Security Requirements (L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)
[17] Standards Mapping - OWASP Mobile 2014 M3 Insufficient Transport Layer Protection
[18] Standards Mapping - OWASP Top 10 2004 A10 Insecure Configuration Management
[19] Standards Mapping - OWASP Top 10 2010 A6 Security Misconfiguration
[20] Standards Mapping - OWASP Top 10 2013 A5 Security Misconfiguration
[21] Standards Mapping - OWASP Top 10 2017 A6 Security Misconfiguration
[22] Standards Mapping - OWASP Top 10 2021 A02 Cryptographic Failures
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.10
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.9
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.4
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.4
[29] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.4
[30] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[31] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[32] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 7.1 - Use of Cryptography
[33] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[34] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 7.1 - Use of Cryptography, Control Objective B.2.3 - Terminal Software Design
[35] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3305 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3305 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3305 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3305 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3305 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3305 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3305 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000590 CAT II, APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000590 CAT II, APSC-DV-001620 CAT II, APSC-DV-001630 CAT II, APSC-DV-001810 CAT I
[57] Standards Mapping - Web Application Security Consortium Version 2.00 Application Misconfiguration (WASC-15), Insufficient Authentication (WASC-01)
[58] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.structural.yaml.kubernetes_misconfiguration_weak_etcd_ssl_certificate.base
Abstract
The framework binder used for binding the HTTP request parameters to the model class has not been explicitly configured to allow, or disallow, certain attributes.
Explanation
To ease development and increase productivity, most modern frameworks allow an object to be automatically instantiated and populated with the HTTP request parameters whose names match an attribute of the class to be bound. Automatic instantiation and population of objects speeds up development, but can lead to serious problems if implemented without caution. Any attribute in the bound classes, or nested classes, will be automatically bound to the HTTP request parameters. Therefore, malicious users will be able to assign a value to any attribute in bound or nested classes, even if they are not exposed to the client through web forms or API contracts.

Example 1: With no additional configuration, the following ASP.NET MVC controller method will bind the HTTP request parameters to any attribute in the RegisterModel or Details classes:


public ActionResult Register(RegisterModel model)
{
if (ModelState.IsValid)
{
try
{
return RedirectToAction("Index", "Home");
}
catch (MembershipCreateUserException e)
{
ModelState.AddModelError("", "");
}
}
return View(model);
}


Where RegisterModel class is defined as:


public class RegisterModel
{
[BindRequired]
[Display(Name = "User name")]
public string UserName { get; set; }

[BindRequired]
[DataType(DataType.Password)]
[Display(Name = "Password")]
public string Password { get; set; }

[DataType(DataType.Password)]
[Display(Name = "Confirm password")]
public string ConfirmPassword { get; set; }

public Details Details { get; set; }

public RegisterModel()
{
Details = new Details();
}
}


and Details class is defined as:


public class Details
{
public bool IsAdmin { get; set; }
...
}
Example 2: When using TryUpdateModel() or UpdateModel() in ASP.NET MVC or Web API applications, the model binder will automatically try to bind all HTTP request parameters by default:


public ViewResult Register()
{
var model = new RegisterModel();
TryUpdateModel<RegisterModel>(model);
return View("detail", model);
}
Example 3: In ASP.NET Web Form applications, the model binder will automatically try to bind all HTTP request parameters when using TryUpdateModel() or UpdateModel() with IValueProvider interface.

Employee emp = new Employee();
TryUpdateModel(emp, new System.Web.ModelBinding.FormValueProvider(ModelBindingExecutionContext));
if (ModelState.IsValid)
{
db.SaveChanges();
}


and Employee class is defined as:


public class Employee
{
public Employee()
{
IsAdmin = false;
IsManager = false;
}
public string Name { get; set; }
public string Email { get; set; }
public bool IsManager { get; set; }
public bool IsAdmin { get; set; }
}
References
[1] OWASP Mass assignment
[2] Standards Mapping - Common Weakness Enumeration CWE ID 915
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001082, CCI-002754
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-2 Application Partitioning (P1), SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-2 Separation of System and User Functionality, SI-10 Information Input Validation
[7] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.2 Input Validation Requirements (L1 L2 L3)
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[11] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[12] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[13] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[14] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[15] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[16] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[29] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.structural.dotnet.mass_assignment_insecure_binder_configuration
Abstract
The framework binder used for binding the HTTP request parameters to the model class has not been explicitly configured to allow, or disallow certain attributes
Explanation
To ease development and increase productivity, most modern frameworks allow an object to be automatically instantiated and populated with the HTTP request parameters whose names match an attribute of the class to be bound. Automatic instantiation and population of objects speeds up development, but can lead to serious problems if implemented without caution. Any attribute in the bound classes, or nested classes, will be automatically bound to the HTTP request parameters. Therefore, malicious users will be able to assign a value to any attribute in bound or nested classes, even if they are not exposed to the client through web forms or API contracts.

Example 1: Using Spring WebFlow with no additional configuration, the following action will bind the HTTP request parameters to any attribute in the Booking class:


<view-state id="enterBookingDetails" model="booking">
<on-render>
<render fragments="body" />
</on-render>
<transition on="proceed" to="reviewBooking">
</transition>
<transition on="cancel" to="cancel" bind="false" />
</view-state>


Where Booking class is defined as:


public class Booking implements Serializable {
private Long id;
private User user;
private Hotel hotel;
private Date checkinDate;
private Date checkoutDate;
private String creditCard;
private String creditCardName;
private int creditCardExpiryMonth;
private int creditCardExpiryYear;
private boolean smoking;
private int beds;
private Set<Amenity> amenities;

// Public Getters and Setters
...
}
References
[1] OWASP Mass assignment
[2] Pivotal Spring MVC Known Vulnerabilities and Issues
[3] Standards Mapping - Common Weakness Enumeration CWE ID 915
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001082, CCI-002754
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-2 Application Partitioning (P1), SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-2 Separation of System and User Functionality, SI-10 Information Input Validation
[8] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.2 Input Validation Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Mobile 2024 M8 Security Misconfiguration
[12] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[13] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[14] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[15] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[16] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[17] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.2
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[30] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[45] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.config.java.mass_assignment_insecure_binder_configuration
Abstract
Allowing database persistent entities to be auto-populated by request parameters can allow an attacker to create unintended records in association entities or update unintended fields in the entity object.
Explanation
Model objects are an object-oriented representation of database entities. They provide convenience methods to load, store, update, and delete associated database entities.
Hibernate, the Microsoft .NET Entity framework, and LINQ are examples of Object Relational Mapping (ORM) frameworks that help you build database-backed model objects.

Many web frameworks strive to make life easier for developers by providing a mechanism for binding request parameters into request-bound objects based on matching request parameter names to model object attribute names (based on matching public getter and setter methods).

If an application uses ORM classes as request-bound objects, then it is likely that a request parameter can modify any field in corresponding model objects and any nested field of an object attribute.

Example 1: The Order, Customer, and Profile are Microsoft .NET Entity persisted classes.

public class Order {
public string ordered { get; set; }
public List<LineItem> LineItems { get; set; }
pubilc virtual Customer Customer { get; set; }
...
}
public class Customer {
public int CustomerId { get; set; }
...
public virtual Profile Profile { get; set; }
...
}
public class Profile {
public int profileId { get; set; }
public string username { get; set; }
public string password { get; set; }
...
}
OrderController is the ASP.NET MVC controller class handling the request:


public class OrderController : Controller{
StoreEntities db = new StoreEntities();
...

public String updateOrder(Order order) {
...
db.Orders.Add(order);
db.SaveChanges();
}
}

Because model entity classes are automatically bound to requests, an attacker may use this vulnerability to update another user's password by adding the following request parameters to the request: "http://www.yourcorp.com/webApp/updateOrder?order.customer.profile.profileId=1234&order.customer.profile.password=urpowned"
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 915
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001082, CCI-002754
[3] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[4] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-2 Application Partitioning (P1), SI-10 Information Input Validation (P1)
[5] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-2 Separation of System and User Functionality, SI-10 Information Input Validation
[6] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[7] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.2 Input Validation Requirements (L1 L2 L3)
[8] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[9] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[10] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[11] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[12] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[13] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[14] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.2
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[27] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[28] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.structural.dotnet.mass_assignment_request_parameters_bound_into_persisted_objects
Abstract
Allowing database persistent entities to be auto-populated by request parameters will let an attacker create unintended records in association entities or update unintended fields in the entity object.
Explanation
Persistent objects are bound to the underlying database and updated automatically by the persistence framework, such as Hibernate or JPA. Allowing these objects to be dynamically bound to the request by Spring MVC will let an attacker inject unexpected values into the database by providing additional request parameters.
Example 1: The Order, Customer, and Profile are Hibernate persisted classes.

public class Order {
String ordered;
List lineItems;
Customer cust;
...
}
public class Customer {
String customerId;
...
Profile p;
...
}
public class Profile {
String profileId;
String username;
String password;
...
}
OrderController is the Spring controller class handling the request:

@Controller
public class OrderController {
...
@RequestMapping("/updateOrder")
public String updateOrder(Order order) {
...
session.save(order);
}
}

Because command classes are automatically bound to the request, an attacker may use this vulnerability to update another user's password by adding the following request parameters to the request: "http://www.yourcorp.com/webApp/updateOrder?order.customer.profile.profileId=1234&order.customer.profile.password=urpowned"
References
[1] Ryan Berg and Dinis Cruz Two Security Vulnerabilities in the Spring Framework's MVC
[2] Standards Mapping - Common Weakness Enumeration CWE ID 915
[3] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001082, CCI-002754
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-2 Application Partitioning (P1), SI-10 Information Input Validation (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-2 Separation of System and User Functionality, SI-10 Information Input Validation
[7] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.2 Input Validation Requirements (L1 L2 L3)
[9] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[10] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[11] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[12] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[13] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[14] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[15] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[28] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[29] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.structural.java.mass_assignment_request_parameters_bound_into_persisted_objects
Abstract
The framework binder used for binding the HTTP request parameters to the model class relies on Input Formatters when the [FromBody] annotation is used.
Explanation
To ease development and increase productivity, most modern frameworks allow an object to be automatically instantiated and populated with the HTTP request parameters whose names match an attribute of the class to be bound. Automatic instantiation and population of objects speeds up development, but can lead to serious problems if implemented without caution. Any attribute in the bound classes, or nested classes, will be automatically bound to the HTTP request parameters. Therefore, malicious users will be able to assign a value to any attribute in bound or nested classes, even if they are not exposed to the client through web forms or API contracts.

In this case, when the [FromBody] annotation is applied to a complex parameter of an action, then any other binding attributes such as [Bind] or [BindNever] applied to the type of the parameter or any of its fields are effectively ignored, which means that mitigation using binding annotations is impossible.

Example 1: In an ASP.NET Core MVC Web Application when the [FromBody] annotation is applied to a parameter of an action, the model binder automatically tries to bind all parameters specified in the body of the request using an Input Formatter. By default, the binder uses the JSON Input Formatter to try and bind all possible parameters that come from the body of the request:


[HttpPost]
public ActionResult Create([FromBody] Product p)
{
return View(p.Name);
}


Note that any binding annotations such as [Bind] or [BindNever] applied to the Product type that follows are ignored due to Input Formatters being used when the [FromBody] annotation is present.


public class Product
{
...
public string Name { get; set; }
public bool IsAdmin { get; set; }
...
}
References
[1] Microsoft [FromBody] attribute
[2] OWASP Mass assignment
[3] Standards Mapping - Common Weakness Enumeration CWE ID 915
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001082, CCI-002754
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-2 Application Partitioning (P1), SI-10 Information Input Validation (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-2 Separation of System and User Functionality, SI-10 Information Input Validation
[8] Standards Mapping - OWASP API 2023 API3 Broken Object Property Level Authorization
[9] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.1.2 Input Validation Requirements (L1 L2 L3)
[10] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[11] Standards Mapping - OWASP Top 10 2004 A1 Unvalidated Input
[12] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[13] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[14] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[15] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[16] Standards Mapping - OWASP Top 10 2021 A08 Software and Data Integrity Failures
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.2
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[29] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[30] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002150 CAT II, APSC-DV-002560 CAT I
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Abuse of Functionality (WASC-42)
desc.structural.dotnet.mass_assignment_request_parameters_bound_via_input_formatters
Abstract
The program might dereference a null-pointer because it does not check the return value of a function that might return null.
Explanation
Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this function call can never fail" and "it doesn't matter if this function call fails". When a programmer ignores the return value from a function, they implicitly state that they are operating under one of these assumptions.
Example 1: The following code does not check to see if the string returned by the Item property is null before calling the member function Equals(), potentially causing a null dereference.


string itemName = request.Item(ITEM_NAME);
if (itemName.Equals(IMPORTANT_ITEM)) {
...
}
...


The traditional defense of this coding error is:

"I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value."

But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 253, CWE ID 690
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [14] CWE ID 476
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [13] CWE ID 476
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [15] CWE ID 476
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [11] CWE ID 476
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [12] CWE ID 476
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [21] CWE ID 476
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)
[13] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[15] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP6080 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP6080 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002400 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[38] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.dotnet.missing_check_against_null
Abstract
The program can dereference a null-pointer because it does not check the return value of a function that might return null.
Explanation
Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this function call can never fail" and "it doesn't matter if this function call fails". When a programmer ignores the return value from a function, they implicitly state that they are operating under one of these assumptions.
Example 1: The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc().


buf = (char*) malloc(req_size);
strncpy(buf, xfer, req_size);


The traditional defense of this coding error is:

"If my program runs out of memory, it will fail. It doesn't matter whether I handle the error or simply allow the program to die with a segmentation fault when it tries to dereference the null-pointer."

This argument ignores three important considerations:

- Depending upon the type and size of the application, it may be possible to free memory that is being used elsewhere so that execution can continue.

- It is impossible for the program to perform a graceful exit if required. If the program performs an atomic operation, it can leave the system in an inconsistent state.

- The programmer has lost the opportunity to record diagnostic information. Did the call to malloc() fail because req_size was too large or because there were too many requests being handled at the same time? Or was it caused by a memory leak that has built up over time? Without handling the error, there is no way to know.
References
[1] J. Viega, G. McGraw Building Secure Software Addison-Wesley
[2] Standards Mapping - Common Weakness Enumeration CWE ID 253, CWE ID 690
[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [14] CWE ID 476
[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [13] CWE ID 476
[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [15] CWE ID 476
[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [11] CWE ID 476
[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [12] CWE ID 476
[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [21] CWE ID 476
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[13] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)
[14] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[16] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP6080 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP6080 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002400 CAT II
[38] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[39] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.cpp.missing_check_against_null
Abstract
The program can dereference a null-pointer because it does not check the return value of a function that might return null.
Explanation
Just about every serious attack on a software system begins with the violation of a programmer's assumptions. After the attack, the programmer's assumptions seem flimsy and poorly founded, but before an attack many programmers would defend their assumptions well past the end of their lunch break.

Two dubious assumptions that are easy to spot in code are "this function call can never fail" and "it doesn't matter if this function call fails". When a programmer ignores the return value from a function, they implicitly state that they are operating under one of these assumptions.

Example 1: The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a null dereference.


String itemName = request.getParameter(ITEM_NAME);
if (itemName.compareTo(IMPORTANT_ITEM)) {
...
}
...
Example 2:. The following code shows a system property that is set to null and later dereferenced by a programmer who mistakenly assumes it will always be defined.


System.clearProperty("os.name");
...
String os = System.getProperty("os.name");
if (os.equalsIgnoreCase("Windows 95") )
System.out.println("Not supported");


The traditional defense of this coding error is:

"I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value."

But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 253, CWE ID 690
[2] Standards Mapping - Common Weakness Enumeration Top 25 2019 [14] CWE ID 476
[3] Standards Mapping - Common Weakness Enumeration Top 25 2020 [13] CWE ID 476
[4] Standards Mapping - Common Weakness Enumeration Top 25 2021 [15] CWE ID 476
[5] Standards Mapping - Common Weakness Enumeration Top 25 2022 [11] CWE ID 476
[6] Standards Mapping - Common Weakness Enumeration Top 25 2023 [12] CWE ID 476
[7] Standards Mapping - Common Weakness Enumeration Top 25 2024 [21] CWE ID 476
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[9] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[10] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[11] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[12] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)
[13] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[14] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[15] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP6080 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP6080 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002400 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[38] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.missing_check_against_null
Abstract
This function violates the contract that it must compare its parameter with null.
Explanation
The Java standard requires that implementations of Object.equals(), Comparable.compareTo(), and Comparator.compare() must return a specified value if their parameters are null. Failing to follow this contract may result in unexpected behavior.

Example 1: The following implementation of the equals() method does not compare its parameter with null.


public boolean equals(Object object)
{
return (toString().equals(object.toString()));
}
References
[1] MET10-J. Follow the general contract when implementing the compareTo() method CERT
[2] MET08-J. Preserve the equality contract when overriding the equals() method CERT
[3] Standards Mapping - Common Weakness Enumeration CWE ID 398
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
desc.controlflow.java.missing_check_for_null_parameter
Abstract
A clone() method should call super.clone() to obtain the new object.
Explanation
All implementations of clone() should obtain the new object by calling super.clone(). If a class fails to follow this convention, a subclass's clone() method will return an object of the wrong type.


Example 1: The following two classes demonstrate a bug introduced by failing to call super.clone(). Because of the way Kibitzer implements clone(), FancyKibitzer's clone method will return an object of type Kibitzer instead of FancyKibitzer.


public class Kibitzer implements Cloneable {
public Object clone() throws CloneNotSupportedException {
Object returnMe = new Kibitzer();
...
}
}

public class FancyKibitzer extends Kibitzer
implements Cloneable {
public Object clone() throws CloneNotSupportedException {
Object returnMe = super.clone();
...
}
}
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 580
desc.structural.java.object_model_violation_erroneous_clone_method
Abstract
This class overrides only one of Equals() and GetHashCode().
Explanation
.NET objects are expected to obey a number of invariants related to equality. One of these invariants is that equal objects must have equal hashcodes. In other words, if a.Equals(b) == true then a.GetHashCode() == b.GetHashCode().

Failure to uphold this invariant is likely to cause trouble if objects of this class are stored in a collection. If the objects of the class in question are used as a key in a Hashtable or if they are inserted into a Dictionary, it is critical that equal objects have equal hashcodes.

Example 1: The following class overrides Equals() but not GetHashCode().


public class Halfway() {
public override boolean Equals(object obj) {
...
}
}
References
[1] MSDN Library: Equals Method (Object) Microsoft Corporation
[2] MSDN Library: GetHashCode Method (Object) Microsoft Corporation
[3] Standards Mapping - Common Weakness Enumeration CWE ID 581
desc.structural.dotnet.object_model_violation.just_one_of_equals_hashcode_defined
Abstract
This class overrides only one of equals() and hashCode().
Explanation
Java objects are expected to obey a number of invariants related to equality. One of these invariants is that equal objects must have equal hashcodes. In other words, if a.equals(b) == true then a.hashCode() == b.hashCode().

Failure to uphold this invariant is likely to cause trouble if objects of this class are stored in a collection. If the objects of the class in question are used as a key in a Hashtable or if they are inserted into a Map or Set, it is critical that equal objects have equal hashcodes.

Example 1: The following class overrides equals() but not hashCode().


public class halfway() {
public boolean equals(Object obj) {
...
}
}
References
[1] D. H. Hovermeyer FindBugs User Manual
[2] MET09-J. Classes that define an equals() method must also define a hashCode() method CERT
[3] Standards Mapping - Common Weakness Enumeration CWE ID 581
desc.structural.java.object_model_violation_just_one_of_equals_hashcode_defined
Abstract
This class overrides only one of saveState() and restoreState().
Explanation
Any class that inherits the StateHolder interface must implement both saveState(javax.faces.context.FacesContext) and restoreState(javax.faces.context.FacesContext, java.lang.Object) or implement neither of them. Because these two methods have a tightly coupled relationship, it is not permissible to have the saveState(javax.faces.context.FacesContext) and restoreState(javax.faces.context.FacesContext, java.lang.Object) methods reside at different levels of the inheritance hierarchy.

Example 1: The following class defines saveState() and not restoreState(), so it is always in error no matter what any class that extends
it might do.

public class KibitzState implements StateHolder {
public Object saveState(FacesContext fc) {
...
}
}
References
[1] Sun Microsystems JavaDoc for StateHolder Interface
[2] Standards Mapping - Common Weakness Enumeration CWE ID 398
desc.structural.java.object_model_violation_just_one_of_restoreState_saveState_defined
Abstract
The functions, checkCallingOrSelfPermission() or checkCallingOrSelfUriPermission(), should be used with care as it allows the calling program, without the required or no permissions, to bypass the permission check, by using your application's permissions.
Explanation
The function checkCallingOrSelfPermission() or checkCallingOrSelfUriPermission() determine whether the calling program has the required permission to access a certain service or a given URI. However, these functions should be used with care as they can grant access to malicious applications, lacking the appropriate permissions, by assuming your applications permissions.

This means a malicious application, without appropriate permissions, can bypass its permission check by using your application's permission to get access to otherwise denied resources. This can result in what is known as the confused deputy attack.
References
[1] Designing for Security Android
[2] Context: Android Developers Android
[3] Standards Mapping - Common Weakness Enumeration CWE ID 275
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002165
[5] Standards Mapping - FIPS200 AC
[6] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[7] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1)
[8] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement
[9] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[10] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.5 Access Control Architectural Requirements (L2 L3)
[11] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[12] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[13] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[14] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[15] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[16] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[17] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[18] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[19] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[28] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[29] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[32] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 863
[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[40] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[55] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.structural.java.often_misused_android_permission_check
Abstract
The code asserts to its callers that a certain permission is given, potentially allowing an attacker to bypass security controls.
Explanation
Permissions in the .NET Framework work by going up the stack tree (where the tree grows downward), to check if permissions are set sufficiently to access a resource. When a developer uses Assert() with a specific permission it is a way to say that the current controlflow has the specified permission. This in turn leads to the .NET framework stopping any further permission checks as long as it satisfies the needed permissions, meaning that code that calls the code making the call to Assert() may not have the required permission. The use of Assert() is helpful in some cases, but can lead to vulnerabilities when this allows a malicious user to get control of a resource that they would not have permission to otherwise.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 275
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000213, CCI-002038, CCI-002039, CCI-002165
[3] Standards Mapping - FIPS200 AC
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-3 Access Enforcement (P1), IA-11 Re-Authentication (P0)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-3 Access Enforcement, SC-11 Trusted Path
[7] Standards Mapping - OWASP API 2023 API1 Broken Object Level Authorization
[8] Standards Mapping - OWASP Application Security Verification Standard 4.0 1.4.5 Access Control Architectural Requirements (L2 L3)
[9] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[10] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[11] Standards Mapping - OWASP Top 10 2004 A2 Broken Access Control
[12] Standards Mapping - OWASP Top 10 2007 A4 Insecure Direct Object Reference
[13] Standards Mapping - OWASP Top 10 2010 A4 Insecure Direct Object References
[14] Standards Mapping - OWASP Top 10 2013 A4 Insecure Direct Object References
[15] Standards Mapping - OWASP Top 10 2017 A5 Broken Access Control
[16] Standards Mapping - OWASP Top 10 2021 A01 Broken Access Control
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.2
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.4
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.4 - Authentication and Access Control
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.4 - Authentication and Access Control
[28] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.4 - Authentication and Access Control, Control Objective C.2.3 - Web Software Access Controls
[29] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 863
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[44] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[45] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[46] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[47] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001520 CAT II, APSC-DV-001530 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000460 CAT I, APSC-DV-000470 CAT II, APSC-DV-001520 CAT II, APSC-DV-001530 CAT II
[52] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authorization (WASC-02)
[53] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authorization
desc.semantic.dotnet.often_misused_asserting_permissions
Abstract
Attackers may spoof DNS entries. Do not rely on DNS names for security.
Explanation
Many DNS servers are susceptible to spoofing attacks, so you should assume that your software will someday run in an environment with a compromised DNS server. If attackers are allowed to make DNS updates (sometimes called DNS cache poisoning), they can route your network traffic through their machines or make it appear as if their IP addresses are part of your domain. Do not base the security of your system on DNS names.
Example 1: The following code sample uses a DNS lookup in order to decide whether or not an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.


IPAddress hostIPAddress = IPAddress.Parse(RemoteIpAddress);
IPHostEntry hostInfo = Dns.GetHostByAddress(hostIPAddress);
if (hostInfo.HostName.EndsWith("trustme.com")) {
trusted = true;
}


IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers may easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 247, CWE ID 292, CWE ID 558, CWE ID 807
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000877
[3] Standards Mapping - FIPS200 IA
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-11 Re-Authentication (P0), MA-4 Nonlocal Maintenance (P2), SC-23 Session Authenticity (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 MA-4 Nonlocal Maintenance, SC-11 Trusted Path, SC-23 Session Authenticity
[7] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[8] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[10] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[11] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[12] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[13] Standards Mapping - OWASP Top 10 2013 A2 Broken Authentication and Session Management
[14] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[15] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807
[29] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3460 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3460 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3460 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3460 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3460 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3460 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3460 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II
[39] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authentication (WASC-01)
[40] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.semantic.dotnet.often_misused_authentication
Abstract
The getlogin() function is easy to spoof. Do not rely on the name it returns.
Explanation
The getlogin() function is supposed to return a string containing the name of the user currently logged in at the terminal, but an attacker may cause getlogin() to return the name of any user logged in to the machine. Do not rely on the name returned by getlogin() when making security decisions.
Example 1: The following code relies on getlogin() to determine whether or not a user is trusted. It is easily subverted.


pwd = getpwnam(getlogin());
if (isTrustedGroup(pwd->pw_gid)) {
allow();
} else {
deny();
}
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 247, CWE ID 292, CWE ID 558, CWE ID 807
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000877
[3] Standards Mapping - FIPS200 IA
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-11 Re-Authentication (P0), MA-4 Nonlocal Maintenance (P2), SC-23 Session Authenticity (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 MA-4 Nonlocal Maintenance, SC-11 Trusted Path, SC-23 Session Authenticity
[7] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[8] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[10] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[11] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[12] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[13] Standards Mapping - OWASP Top 10 2013 A2 Broken Authentication and Session Management
[14] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[15] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807
[29] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3460 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3460 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3460 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3460 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3460 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3460 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3460 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II
[39] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authentication (WASC-01)
[40] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.semantic.cpp.often_misused_authentication.getlogin
Abstract
Attackers may spoof DNS entries. Do not rely on DNS names for security.
Explanation
Many DNS servers are susceptible to spoofing attacks, so you should assume that your software will someday run in an environment with a compromised DNS server. If attackers are allowed to make DNS updates (sometimes called DNS cache poisoning), they can route your network traffic through their machines or make it appear as if their IP addresses are part of your domain. Do not base the security of your system on DNS names.
Example 1: The following code uses a DNS lookup to determine whether an inbound request is from a trusted host. If an attacker can poison the DNS cache, they can gain trusted status.


String ip = request.getRemoteAddr();
InetAddress addr = InetAddress.getByName(ip);
if (addr.getCanonicalHostName().endsWith("trustme.com")) {
trusted = true;
}


IP addresses are more reliable than DNS names, but they can also be spoofed. Attackers may easily forge the source IP address of the packets they send, but response packets will return to the forged IP address. To see the response packets, the attacker has to sniff the traffic between the victim machine and the forged IP address. In order to accomplish the required sniffing, attackers typically attempt to locate themselves on the same subnet as the victim machine. Attackers may be able to circumvent this requirement by using source routing, but source routing is disabled across much of the Internet today. In summary, IP address verification can be a useful part of an authentication scheme, but it should not be the single factor required for authentication.
References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 247, CWE ID 292, CWE ID 558, CWE ID 807
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-000877
[3] Standards Mapping - FIPS200 IA
[4] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation
[5] Standards Mapping - NIST Special Publication 800-53 Revision 4 IA-11 Re-Authentication (P0), MA-4 Nonlocal Maintenance (P2), SC-23 Session Authenticity (P1)
[6] Standards Mapping - NIST Special Publication 800-53 Revision 5 MA-4 Nonlocal Maintenance, SC-11 Trusted Path, SC-23 Session Authenticity
[7] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication
[8] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization
[9] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1
[10] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management
[11] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management
[12] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management
[13] Standards Mapping - OWASP Top 10 2013 A2 Broken Authentication and Session Management
[14] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication
[15] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.10
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[25] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[26] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[27] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
[28] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807
[29] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807
[30] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3460 CAT I
[31] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3460 CAT I
[32] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3460 CAT I
[33] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3460 CAT I
[34] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3460 CAT I
[35] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3460 CAT I
[36] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3460 CAT I
[37] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II
[39] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authentication (WASC-01)
[40] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication
desc.semantic.java.often_misused_authentication
Abstract
The method Boolean.getBoolean() is often confused with Boolean.valueOf() or Boolean.parseBoolean() method calls.
Explanation
In most cases, a call to Boolean.getBoolean() is often misused as it is assumed to return the boolean value represented by the specified string argument. However, as stated in the Javadoc Boolean.getBoolean(String) method "Returns true if and only if the system property named by the argument exists and is equal to the string 'true'."

Most often what the developer intended to use was a call to Boolean.valueOf(String) or Boolean.parseBoolean(String) method.
Example 1: The following code will not behave as expected. It will print "FALSE" as Boolean.getBoolean(String) does not translate a String primitive. It only translates system property.

...
String isValid = "true";
if ( Boolean.getBoolean(isValid) ) {
System.out.println("TRUE");
}
else {
System.out.println("FALSE");
}
...
References
[1] Class Boolean Oracle
[2] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.6
[3] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.6
[4] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.6
[5] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.6
[6] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[7] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4
[8] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[9] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection
[10] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection
desc.semantic.java.often_misused_boolean_getboolean