Reino: Input Validation and Representation
Problemas de validação e representação da entrada são causados por metacaracteres, codificações alternativas e representações numéricas. Confiar na entrada resulta em problemas de segurança. Os problemas incluem: “Buffer Overflows”, ataques de “Cross-Site Scripting”, “SQL Injection”, entre outros.
LDAP Injection
Abstract
A construção de um filtro LDAP dinâmico com uma entrada de usuário pode permitir que um invasor modifique o significado da instrução.
Explanation
Erros de injeção de LDAP ocorrem quando:
1. Os dados entram em um programa por uma fonte não confiável.
Nesse caso, o Fortify Static Code Analyzer não conseguiu determinar se a fonte dos dados é confiável.
2. Os dados são usados para construir dinamicamente um filtro LDAP.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta LDAP que recupera registros para todos os funcionários subordinados a um determinado gerente. O nome do gerente é lido de uma solicitação HTTP e, portanto, não é confiável.
Em condições normais, como ao procurar funcionários subordinados ao gerente João da Silva, o filtro que esse código executa será parecido com o seguinte:
No entanto, como o filtro é construído dinamicamente por meio da concatenação de uma cadeia de consulta base constante e de uma cadeia de entrada do usuário, o comportamento da consulta só será correto se
Com base nas permissões com as quais a consulta é executada, a adição da condição
1. Os dados entram em um programa por uma fonte não confiável.
Nesse caso, o Fortify Static Code Analyzer não conseguiu determinar se a fonte dos dados é confiável.
2. Os dados são usados para construir dinamicamente um filtro LDAP.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta LDAP que recupera registros para todos os funcionários subordinados a um determinado gerente. O nome do gerente é lido de uma solicitação HTTP e, portanto, não é confiável.
...
DirectorySearcher src =
new DirectorySearcher("(manager=" + managerName.Text + ")");
src.SearchRoot = de;
src.SearchScope = SearchScope.Subtree;
foreach(SearchResult res in src.FindAll()) {
...
}
Em condições normais, como ao procurar funcionários subordinados ao gerente João da Silva, o filtro que esse código executa será parecido com o seguinte:
(manager=Smith, John)
No entanto, como o filtro é construído dinamicamente por meio da concatenação de uma cadeia de consulta base constante e de uma cadeia de entrada do usuário, o comportamento da consulta só será correto se
managerName
não contiver metacaracteres LDAP. Se um invasor inserir a string Hacker, Wiley)(|(objectclass=*)
para managerName
, a consulta se tornará a seguinte:
(manager=Hacker, Wiley)(|(objectclass=*))
Com base nas permissões com as quais a consulta é executada, a adição da condição
|(objectclass=*)
faz com que o filtro seja correspondido com todas as entradas do diretório e permite que o invasor recupere informações sobre o grupo inteiro de usuários. A amplitude desse ataque pode ser limitada dependendo das permissões com as quais a consulta LDAP é realizada. Porém, se o invasor puder controlar a estrutura de comandos da consulta, esse ataque poderá afetar pelo menos todos os registros que podem ser acessados pelo usuário com base no qual a consulta LDAP é executada.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 90
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.7 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[14] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A1 Injection
[19] Standards Mapping - OWASP Top 10 2021 A03 Injection
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[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 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[32] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[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-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 LDAP Injection (WASC-29)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 LDAP Injection
desc.semantic.dotnet.ldap_injection
Abstract
A construção de um filtro LDAP dinâmico com uma entrada de usuário pode permitir que um invasor modifique o significado da instrução.
Explanation
Erros de injeção de LDAP ocorrem quando:
1. Os dados entram em um programa por uma fonte não confiável.
2. Os dados são usados para construir dinamicamente um filtro LDAP.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta LDAP que recupera registros para todos os funcionários subordinados a um determinado gerente. O nome do gerente é lido a partir de um soquete de rede e, portanto, não é confiável.
Em condições normais, como ao procurar funcionários subordinados ao gerente João da Silva, o filtro que esse código executa será parecido com o seguinte:
No entanto, como o filtro é construído dinamicamente por meio da concatenação de uma cadeia de consulta base constante e de uma cadeia de entrada do usuário, o comportamento da consulta só será correto se
Com base nas permissões com as quais a consulta é executada, a adição da condição
1. Os dados entram em um programa por uma fonte não confiável.
2. Os dados são usados para construir dinamicamente um filtro LDAP.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta LDAP que recupera registros para todos os funcionários subordinados a um determinado gerente. O nome do gerente é lido a partir de um soquete de rede e, portanto, não é confiável.
fgets(manager, sizeof(manager), socket);
snprintf(filter, sizeof(filter, "(manager=%s)", manager);
if ( ( rc = ldap_search_ext_s( ld, FIND_DN, LDAP_SCOPE_BASE,
filter, NULL, 0, NULL, NULL, LDAP_NO_LIMIT,
LDAP_NO_LIMIT, &result ) ) == LDAP_SUCCESS ) {
...
}
Em condições normais, como ao procurar funcionários subordinados ao gerente João da Silva, o filtro que esse código executa será parecido com o seguinte:
(manager=Smith, John)
No entanto, como o filtro é construído dinamicamente por meio da concatenação de uma cadeia de consulta base constante e de uma cadeia de entrada do usuário, o comportamento da consulta só será correto se
manager
não contiver metacaracteres LDAP. Se um invasor inserir a string Hacker, Wiley)(|(objectclass=*)
para manager
, a consulta se tornará a seguinte:
(manager=Hacker, Wiley)(|(objectclass=*))
Com base nas permissões com as quais a consulta é executada, a adição da condição
|(objectclass=*)
faz com que o filtro seja correspondido com todas as entradas do diretório e permite que o invasor recupere informações sobre o grupo inteiro de usuários. A amplitude desse ataque pode ser limitada dependendo das permissões com as quais a consulta LDAP é realizada. Porém, se o invasor puder controlar a estrutura de comandos da consulta, esse ataque poderá afetar pelo menos todos os registros que podem ser acessados pelo usuário com base no qual a consulta LDAP é executada.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 90
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.7 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[14] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A1 Injection
[19] Standards Mapping - OWASP Top 10 2021 A03 Injection
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[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 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[32] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[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-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 LDAP Injection (WASC-29)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 LDAP Injection
desc.dataflow.cpp.ldap_injection
Abstract
A construção de um filtro LDAP dinâmico com uma entrada de usuário pode permitir que um invasor modifique o significado da instrução.
Explanation
Erros de injeção de LDAP ocorrem quando:
1. Os dados entram em um programa por uma fonte não confiável.
2. Os dados são usados para construir dinamicamente um filtro LDAP.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta LDAP que recupera registros para todos os funcionários subordinados a um determinado gerente. O nome do gerente é lido de uma solicitação HTTP e, portanto, não é confiável.
Em condições normais, como ao procurar funcionários subordinados ao gerente João da Silva, o filtro que esse código executa será parecido com o seguinte:
No entanto, como o filtro é construído dinamicamente por meio da concatenação de uma cadeia de consulta base constante e de uma cadeia de entrada do usuário, o comportamento da consulta só será correto se
Com base nas permissões com as quais a consulta é executada, a adição da condição
1. Os dados entram em um programa por uma fonte não confiável.
2. Os dados são usados para construir dinamicamente um filtro LDAP.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta LDAP que recupera registros para todos os funcionários subordinados a um determinado gerente. O nome do gerente é lido de uma solicitação HTTP e, portanto, não é confiável.
...
DirContext ctx = new InitialDirContext(env);
String managerName = request.getParameter("managerName");
//retrieve all of the employees who report to a manager
String filter = "(manager=" + managerName + ")";
NamingEnumeration employees = ctx.search("ou=People,dc=example,dc=com",
filter);
...
Em condições normais, como ao procurar funcionários subordinados ao gerente João da Silva, o filtro que esse código executa será parecido com o seguinte:
(manager=Smith, John)
No entanto, como o filtro é construído dinamicamente por meio da concatenação de uma cadeia de consulta base constante e de uma cadeia de entrada do usuário, o comportamento da consulta só será correto se
managerName
não contiver metacaracteres LDAP. Se um invasor inserir a string Hacker, Wiley)(|(objectclass=*)
para managerName
, a consulta se tornará a seguinte:
(manager=Hacker, Wiley)(|(objectclass=*))
Com base nas permissões com as quais a consulta é executada, a adição da condição
|(objectclass=*)
faz com que o filtro seja correspondido com todas as entradas do diretório e permite que o invasor recupere informações sobre o grupo inteiro de usuários. A amplitude desse ataque pode ser limitada dependendo das permissões com as quais a consulta LDAP é realizada. Porém, se o invasor puder controlar a estrutura de comandos da consulta, esse ataque poderá afetar pelo menos todos os registros que podem ser acessados pelo usuário com base no qual a consulta LDAP é executada.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 90
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.7 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[14] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A1 Injection
[19] Standards Mapping - OWASP Top 10 2021 A03 Injection
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[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 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[32] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[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-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 LDAP Injection (WASC-29)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 LDAP Injection
desc.dataflow.java.ldap_injection
Abstract
A construção de um filtro LDAP dinâmico com uma entrada de usuário pode permitir que um invasor modifique o significado da instrução.
Explanation
Erros de injeção de LDAP ocorrem quando:
1. Os dados entram em um programa por uma fonte não confiável.
2. Os dados são usados para construir dinamicamente um filtro LDAP.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta LDAP que recupera registros para todos os funcionários subordinados a um determinado gerente. O nome do gerente é lido de uma solicitação HTTP e, portanto, não é confiável.
Em condições normais, como ao procurar funcionários subordinados ao gerente João da Silva, o filtro que esse código executa será parecido com o seguinte:
No entanto, como o filtro é construído dinamicamente por meio da concatenação de uma cadeia de consulta base constante e de uma cadeia de entrada do usuário, o comportamento da consulta só será correto se
Com base nas permissões com as quais a consulta é executada, a adição da condição
1. Os dados entram em um programa por uma fonte não confiável.
2. Os dados são usados para construir dinamicamente um filtro LDAP.
Exemplo 1: O código a seguir constrói e executa dinamicamente uma consulta LDAP que recupera registros para todos os funcionários subordinados a um determinado gerente. O nome do gerente é lido de uma solicitação HTTP e, portanto, não é confiável.
...
$managerName = $_POST["managerName"]];
//retrieve all of the employees who report to a manager
$filter = "(manager=" . $managerName . ")";
$result = ldap_search($ds, "ou=People,dc=example,dc=com", $filter);
...
Em condições normais, como ao procurar funcionários subordinados ao gerente João da Silva, o filtro que esse código executa será parecido com o seguinte:
(manager=Smith, John)
No entanto, como o filtro é construído dinamicamente por meio da concatenação de uma cadeia de consulta base constante e de uma cadeia de entrada do usuário, o comportamento da consulta só será correto se
managerName
não contiver metacaracteres LDAP.Se um invasor inserir a string Hacker, Wiley)(|(objectclass=*)
para managerName
, a consulta se tornará a seguinte:
(manager=Hacker, Wiley)(|(objectclass=*))
Com base nas permissões com as quais a consulta é executada, a adição da condição
|(objectclass=*)
faz com que o filtro seja correspondido com todas as entradas do diretório e permite que o invasor recupere informações sobre o grupo inteiro de usuários.A amplitude desse ataque pode ser limitada dependendo das permissões com as quais a consulta LDAP é realizada. Porém, se o invasor puder controlar a estrutura de comandos da consulta, esse ataque poderá afetar pelo menos todos os registros que podem ser acessados pelo usuário com base no qual a consulta LDAP é executada.References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 90
[2] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002754
[3] Standards Mapping - FIPS200 SI
[4] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[5] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 1.3
[6] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C Guidelines 2023 Directive 4.14, Rule 1.3
[7] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 0-3-1
[8] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2023 Rule 4.1.3
[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.7 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[12] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[13] Standards Mapping - OWASP Mobile 2024 M4 Insufficient Input/Output Validation
[14] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[15] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[16] Standards Mapping - OWASP Top 10 2010 A1 Injection
[17] Standards Mapping - OWASP Top 10 2013 A1 Injection
[18] Standards Mapping - OWASP Top 10 2017 A1 Injection
[19] Standards Mapping - OWASP Top 10 2021 A03 Injection
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[23] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[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 4.2 - Critical Asset Protection
[30] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[31] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[32] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 116
[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-002560 CAT I
[41] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002560 CAT I
[42] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002560 CAT I
[43] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002560 CAT I
[44] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002560 CAT I
[45] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002560 CAT I
[46] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002560 CAT I
[47] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002560 CAT I
[48] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002560 CAT I
[49] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002560 CAT I
[50] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002560 CAT I
[51] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002560 CAT I
[52] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002560 CAT I
[53] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[54] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-002530 CAT II, APSC-DV-002560 CAT I
[55] Standards Mapping - Web Application Security Consortium Version 2.00 LDAP Injection (WASC-29)
[56] Standards Mapping - Web Application Security Consortium 24 + 2 LDAP Injection
desc.dataflow.php.ldap_injection