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.

Often Misused: Authentication

Abstract

Os invasores podem falsificar entradas de DNS. Não confie em nomes DNS para segurança.

Explanation

Muitos servidores DNS são suscetíveis a ataques de falsificação e, portanto, você deve partir do princípio de que algum dia o seu software será executado em um ambiente com um servidor DNS comprometido. Se os invasores tiverem permissão para fazer atualizações de DNS (processo às vezes chamado de envenenamento de cache de DNS), eles poderão rotear seu tráfego de rede através das máquinas deles ou causar a impressão de que os endereços IP deles fazem parte do seu domínio. Não baseie a segurança do seu sistema em nomes DNS.
Exemplo: A amostra de código a seguir usa uma pesquisa de DNS para decidir se uma solicitação de entrada é ou não proveniente de um host confiável. Se um invasor puder envenenar o cache de DNS, ele poderá obter um status confiável.


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

Endereços IP são mais confiáveis que nomes DNS, mas também podem ser falsificados. Os invasores podem facilmente falsificar o endereço IP de origem dos pacotes que eles enviam, mas os pacotes de resposta retornarão ao endereço IP falsificado. Para ver os pacotes de resposta, o invasor precisa realizar o sniffing do tráfego entre a máquina da vítima e o endereço IP falsificado. Para realizar o sniffing necessário, os invasores normalmente tentam se localizar na mesma sub-rede que a máquina da vítima. Os invasores podem ser capazes de se esquivar dessa exigência usando o roteamento de origem, mas esse roteamento não está habilitado em uma grande extensão da Internet hoje em dia. Em resumo, a verificação de endereços IP pode ser uma parte útil de um esquema de autenticação, mas não deve ser o único fator necessário para a autenticação.

References

[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1

[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial

[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 1

[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 4

[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity

[6] Standards Mapping - Common Weakness Enumeration CWE ID 247, CWE ID 292, CWE ID 558, CWE ID 807

[7] Standards Mapping - FIPS200 IA

[8] Standards Mapping - General Data Protection Regulation (GDPR) Access Violation

[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-23 Session Authenticity (P1)

[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-23 Session Authenticity

[11] Standards Mapping - OWASP Top 10 2004 A3 Broken Authentication and Session Management

[12] Standards Mapping - OWASP Top 10 2007 A7 Broken Authentication and Session Management

[13] Standards Mapping - OWASP Top 10 2010 A3 Broken Authentication and Session Management

[14] Standards Mapping - OWASP Top 10 2013 A2 Broken Authentication and Session Management

[15] Standards Mapping - OWASP Top 10 2017 A2 Broken Authentication

[16] Standards Mapping - OWASP Top 10 2021 A07 Identification and Authentication Failures

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

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

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

[20] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.3

[21] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.5.7

[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.10

[24] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.10

[25] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.10

[26] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.10

[27] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4

[28] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection

[29] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection

[30] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection

[31] Standards Mapping - SANS Top 25 2010 Porous Defenses - CWE ID 807

[32] Standards Mapping - SANS Top 25 2011 Porous Defenses - CWE ID 807

[33] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3460 CAT I

[34] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3460 CAT I

[35] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3460 CAT I

[36] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3460 CAT I

[37] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3460 CAT I

[38] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3460 CAT I

[39] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3460 CAT I

[40] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-001520 CAT II, APSC-DV-001530 CAT II, APSC-DV-001970 CAT II

[41] Standards Mapping - Web Application Security Consortium Version 2.00 Insufficient Authentication (WASC-01)

[42] Standards Mapping - Web Application Security Consortium 24 + 2 Insufficient Authentication

desc.semantic.dotnet.often_misused_authentication

Abstract

A função getlogin() é fácil de falsificar. Não confie no nome que ela retorna.

Explanation

A função getlogin() deve retornar uma string contendo o nome do usuário atualmente conectado ao terminal, mas um invasor pode fazer com que getlogin() retorne o nome de qualquer usuário conectado à máquina. Não confie no nome retornado por getlogin() ao tomar decisões de segurança.
Exemplo 1: O código a seguir se baseia em getlogin() para determinar se um usuário é ou não confiável. Isso é facilmente contestado.


 pwd = getpwnam(getlogin());
 if (isTrustedGroup(pwd->pw_gid)) {
 allow();
 } else {
 deny();
 }