Reino: API Abuse

Uma API é um contrato entre quem chama e o que se chama. As formas mais comuns de abuso de API ocorrem quando o responsável pela chamada não respeita sua parte do contrato. Por exemplo, se um programa não chama chdir() após chamar chroot(), ele viola o contrato que especifica como alterar o diretório raiz ativo de forma segura. Outro bom exemplo de abuso de biblioteca é esperar que o elemento chamado retorne informações confiáveis de DNS ao responsável pela chamada. Nesse caso, o responsável pela chamada abusa a API do elemento chamado ao fazer certas suposições sobre seu comportamento (isto é, que o valor de retorno pode ser usado para fins de autenticação). A outra parte também pode violar o contrato entre quem chama e o que se chama. Por exemplo, se um programador definir SecureRandom como subclasse e retornar um valor não aleatório, o contrato será violado.

Password Management: Weak Redundancy

Java/JSP

Abstract

Para fins de confirmação de senha, a nova senha deve ser fornecida duas vezes em vez de duplicada.

Explanation

Alterar uma senha ou criar uma nova conta de usuário geralmente requer que a nova senha seja fornecida duas vezes para fins de confirmação. Passar uma senha duplicada em vez de passá-la duas vezes evita que a API verifique se o usuário não digitou a senha incorretamente e contorna o mecanismo de segurança de confirmação de senha.

Exemplo 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