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.

Missing Check against Null

Abstract

O programa pode desfazer a referência a um ponteiro nulo porque ele não verifica o valor de retorno de uma função que pode ser null.

Explanation

Quase todos os ataques sérios em um sistema de software começam com a violação das premissas de um programador. Depois do ataque, essas premissas parecem frágeis e infundadas, mas, antes dele, muitos programadores as defenderiam com grande veemência.

Duas suposições duvidosas que são fáceis de detectar no código são "essa chamada de função nunca pode falhar" e "não importa se essa chamada de função falhar". Quando um programador ignora o valor de retorno de uma função, ele afirma implicitamente estar operando de acordo com uma dessas suposições.
Exemplo 1: O código a seguir não verifica se a string retornada pela propriedade Item é null antes de chamar a função membro Equals(), causando possivelmente um cancelamento de referência null


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

A defesa tradicional desse erro de codificação é:

"Sei que o valor solicitado sempre existirá porque... Se não existir, o programa não poderá executar o comportamento desejado e, portanto, não importa se eu manipular o erro ou simplesmente permitir que o programa se torne inativo ao tentar desfazer a referência a um valor null."

Porém, os invasores são hábeis em encontrar caminhos inesperados através de programas, particularmente quando exceções estão envolvidas.

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 - DISA Control Correlation Identifier Version 2 CCI-001094

[8] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data

[9] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)

[10] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection

[11] Standards Mapping - OWASP Application Security Verification Standard 4.0 11.1.7 Business Logic Security Requirements (L2 L3)

[12] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service

[13] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9

[14] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3120 CAT II, APP6080 CAT II

[15] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3120 CAT II, APP6080 CAT II

[16] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3120 CAT II, APP6080 CAT II

[17] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3120 CAT II, APP6080 CAT II

[18] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3120 CAT II, APP6080 CAT II

[19] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3120 CAT II, APP6080 CAT II

[20] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3120 CAT II, APP6080 CAT II

[21] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II

[22] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II

[23] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II

[24] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II

[25] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II

[26] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II

[27] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II

[28] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II

[29] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II

[30] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II

[31] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II

[32] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II

[33] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II

[34] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II

[35] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)

[36] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service

desc.controlflow.dotnet.missing_check_against_null

Abstract

O programa pode desreferenciar um ponteiro nulo porque ele não verifica o valor de retorno de uma função que pode ser null.

Explanation

Quase todos os ataques sérios em um sistema de software começam com a violação das premissas de um programador. Depois do ataque, essas premissas parecem frágeis e infundadas, mas, antes dele, muitos programadores as defenderiam com grande veemência.

Duas suposições duvidosas que são fáceis de detectar no código são "essa chamada de função nunca pode falhar" e "não importa se essa chamada de função falhar". Quando um programador ignora o valor de retorno de uma função, ele afirma implicitamente estar operando de acordo com uma dessas suposições.
Exemplo 1: O código a seguir não verifica se a alocação de memória foi bem-sucedida antes de tentar usar o ponteiro retornado por malloc().


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

A defesa tradicional desse erro de codificação é:

"Se meu programa ficar sem memória, ele falhará. Não importa se eu tratar o erro ou simplesmente permitir que o programa se torne inativo com uma falha de segmentação ao tentar desreferenciar o ponteiro nulo."

Esse argumento ignora três considerações importantes:

- Dependendo do tipo e do tamanho do aplicativo, pode ser possível liberar a memória que está sendo usada em outro local para que a execução possa continuar.

- É impossível para o programa realizar uma saída normal, se necessário. Se o programa realizar uma operação atômica, ele poderá deixar o sistema em estado inconsistente.

- O programador perdeu a oportunidade de registrar informações de diagnóstico. A chamada para malloc() falhou por que req_size era grande demais ou por que muitas solicitações estavam sendo tratadas ao mesmo tempo? Ou ela foi causada por um vazamento de memória que se acumulou com o passar do tempo? Sem realizar o tratamento do erro, não há como saber.

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 - 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 - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)

[37] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service

desc.controlflow.cpp.missing_check_against_null

Abstract

O programa pode desreferenciar um ponteiro nulo porque ele não verifica o valor de retorno de uma função que pode ser null.

Explanation

Quase todos os ataques sérios em um sistema de software começam com a violação das premissas de um programador. Depois do ataque, essas premissas parecem frágeis e infundadas, mas, antes dele, muitos programadores as defenderiam com grande veemência.

Duas suposições duvidosas que são fáceis de detectar no código são "essa chamada de função nunca pode falhar" e "não importa se essa chamada de função falhar". Quando um programador ignora o valor de retorno de uma função, ele afirma implicitamente estar operando de acordo com uma dessas suposições.

Exemplo 1: O código a seguir não verifica se a string retornada por getParameter() é null antes de chamar a função membro compareTo(), causando possivelmente um cancelamento de referência null.


String itemName = request.getParameter(ITEM_NAME);
	if (itemName.compareTo(IMPORTANT_ITEM)) {
		...
	}
	...

Exemplo 2:. O código a seguir mostra uma propriedade do sistema que é definida como null e, mais tarde, tem sua referência desfeita por um programador, que erroneamente assume que ela sempre será definida.


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