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.

Password Management: Weak Redundancy

Java/JSP

Abstract

For password confirmation purposes, the new password should be provided twice instead of duplicated.

Explanation

Changing a password or creating a new user account usually requires the new password to be provided twice for confirmation purposes. Passing a duplicated password instead of passing it twice prevents the API from making sure that the user did not mistype the password and circumvents the safety mechanism of password confirmation.

Example 1:


    String password=request.getParameter("password");
    ...
    DefaultUser user = (DefaultUser) ESAPI.authenticator().createUser(username, password, password);

References

[1] OWASP ESAPI Secure Coding API: User

[2] Standards Mapping - Common Weakness Enumeration CWE ID 521

[3] Standards Mapping - Common Weakness Enumeration Top 25 2019 [13] CWE ID 287

[4] Standards Mapping - Common Weakness Enumeration Top 25 2020 [14] CWE ID 287

[5] Standards Mapping - Common Weakness Enumeration Top 25 2021 [14] CWE ID 287

[6] Standards Mapping - Common Weakness Enumeration Top 25 2022 [14] CWE ID 287

[7] Standards Mapping - Common Weakness Enumeration Top 25 2023 [13] CWE ID 287

[8] Standards Mapping - Common Weakness Enumeration Top 25 2024 [14] CWE ID 287

[9] Standards Mapping - FIPS200 IA

[10] Standards Mapping - General Data Protection Regulation (GDPR) Insufficient Data Protection

[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 2.1.11 Password Security Requirements (L1 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), 2.10.1 Service Authentication Requirements (L2 L3), 2.10.2 Service Authentication Requirements (L2 L3), 3.7.1 Defenses Against Session Management Exploits (L1 L2 L3), 9.2.3 Server Communications Security Requirements (L2 L3)

[12] Standards Mapping - OWASP Mobile 2014 M5 Poor Authorization and Authentication

[13] Standards Mapping - OWASP Mobile 2024 M3 Insecure Authentication/Authorization

[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-AUTH-1

[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.8, Requirement 8.4

[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.3, Requirement 6.5.8, Requirement 8.4

[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.4

[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1

[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1

[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1

[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.3.1, Requirement 6.5.3, Requirement 8.2.1

[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4, Requirement 6.5.4, Requirement 6.5.6, Requirement 8.3.1

[23] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0.1 Requirement 6.2.4, Requirement 6.5.4, Requirement 6.5.6, Requirement 8.3.1

[24] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 5.3 - Authentication and Access Control, Control Objective 7 - Use of Cryptography

[25] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 5.3 - Authentication and Access Control, Control Objective 7 - Use of Cryptography

[26] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 5.3 - Authentication and Access Control, Control Objective 7 - Use of Cryptography, Control Objective C.2.1.2 - Web Software Access Controls

desc.structural.java.password_management_weak_redundancy