Reino: Code Quality

Códigos de baixa qualidade levam a comportamentos imprevisíveis. Da perspectiva do usuário, isso normalmente se manifesta como usabilidade ruim. Para um invasor, trata-se de uma oportunidade para atacar o sistema de formas imprevistas.

93 itens encontrados
Vulnerabilidades
Abstract
Uma PendingIntent foi detectada com seu valor de sinalizador definido como FLAG_MUTABLE. Intenções pendentes criadas com o valor do sinalizador de FLAG_MUTABLE são suscetíveis a ter campos não especificados Intent definido a jusante, que pode modificar a capacidade da Intent e deixar o sistema aberto a vulnerabilidades.
Explanation
Permitindo a modificação da Intent subjacente de uma PendingIntent após sua criação pode deixar um sistema aberto a ataques. Isso depende principalmente da capacidade geral da Intent subjacente. Na maioria dos casos, é uma prática recomendada evitar possíveis problemas definindo o sinalizador PendingIntent como FLAG_IMMUTABLE.

Exemplo 1: O seguinte inclui uma PendingIntent criada com um valor de sinalizador de FLAG_MUTABLE.


...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE

val pi_flagmutable = PendingIntent.getService(
this,
0,
intent_flag_mut,
flag_mut
)
...
References
[1] Remediation for Implicit PendingIntent Vulnerability
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 4
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Cloud Computing Platform Benchmark partial
[7] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[8] Standards Mapping - CIS Kubernetes Benchmark partial
[9] Standards Mapping - Common Weakness Enumeration CWE ID 99
[10] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[11] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[12] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[13] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[14] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.1
[16] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.4
[17] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.8
[18] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.8
[19] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.8
[20] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.8
[21] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.8
[22] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[23] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[37] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[38] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[39] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[40] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[41] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[42] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[43] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[44] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[45] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.java.intent_manipulation_mutable_pending_intent
Abstract
A memória é alocada, mas nunca é liberada.
Explanation
Vazamentos de memória têm duas causas em comum, às vezes sobrepostas:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável por liberar a memória.

A maioria dos vazamentos de memória resultará em problemas gerais de confiabilidade de software, mas, se um invasor puder provocar intencionalmente um vazamento de memória, talvez ele consiga lançar um ataque de negação de serviço (fazendo com que o programa trave) ou tirar proveito de outro comportamento inesperado do programa resultante de uma condição de pouca memória [1].

Exemplo 1: A função C a seguir faz vazar um bloco de memória alocada quando a chamada para read() não consegue retornar o número esperado de bytes:


char* getBlock(int fd) {
char* buf = (char*) malloc(BLOCK_SIZE);
if (!buf) {
return NULL;
}
if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {
return NULL;
}
return buf;
}
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
desc.controlflow.cpp.memory_leak
Abstract
A memória é alocada, mas nunca é liberada.
Explanation
Vazamentos de memória têm duas causas comuns e, às vezes, sobrepostas:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação de memória.

A maioria dos vazamentos de memória resulta em problemas gerais de confiabilidade de software, mas se um invasor puder acionar intencionalmente um vazamento de memória, poderá lançar um ataque de denial of service (travando o programa) ou tirar vantagem de outro comportamento inesperado do programa resultante de uma condição de pouca memória [1].

Exemplo 1: O seguinte programa COBOL da Micro Focus vazará um bloco de memória alocada se ocorrer um erro:


CALL "CBL_ALLOC_MEM"
USING mem-pointer
BY VALUE mem-size
BY VALUE flags
RETURNING status-code
END-CALL

IF status-code NOT = 0
DISPLAY "Error!"
GOBACK
ELSE
SET ADDRESS OF mem TO mem-pointer
END-IF

PERFORM write-data
IF ws-status-code NOT = 0
DISPLAY "Error!"
GOBACK
ELSE
DISPLAY "Success!"
END-IF

CALL "CBL_FREE_MEM"
USING BY VALUE mem-pointer
RETURNING status-code
END-CALL

GOBACK
.
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
desc.controlflow.cobol.memory_leak
Abstract
Um objeto aloca memória para uma variável de membro e falha em liberá-la no método dealloc().
Explanation
Vazamentos de memória têm duas causas em comum, às vezes sobrepostas:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável por liberar a memória.

A maioria dos vazamentos de memória resultará em problemas gerais de confiabilidade de software, mas, se um invasor puder provocar intencionalmente um vazamento de memória, talvez ele consiga lançar um ataque de negação de serviço (fazendo com que o programa trave) ou tirar proveito de outro comportamento inesperado do programa resultante de uma condição de pouca memória [1].

Exemplo 1: O objeto Objective-C aloca memória no método init() mas falha em liberá-la no método deallocate() resultando em um vazamento de memória:


- (void)init
{
myVar = [NSString alloc] init];
...
}

- (void)dealloc
{
[otherVar release];
}
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
desc.structural.objc.memory_leak
Abstract
O programa redimensiona um bloco de memória alocada. Se o redimensionamento falhar, ocorrerá um vazamento no bloco original.
Explanation
Vazamentos de memória têm duas causas em comum, às vezes sobrepostas:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável por liberar a memória.

A maioria dos vazamentos de memória resultará em problemas gerais de confiabilidade de software, mas, se um invasor puder provocar intencionalmente um vazamento de memória, talvez ele consiga lançar um ataque de negação de serviço (fazendo com que o programa trave) ou tirar proveito de outro comportamento inesperado do programa resultante de uma condição de pouca memória [1].

Exemplo 1: A seguinte função C faz vazar um bloco de memória alocada quando a chamada realloc() não consegue redimensionar a alocação original.


char* getBlocks(int fd) {
int amt;
int request = BLOCK_SIZE;
char* buf = (char*) malloc(BLOCK_SIZE + 1);
if (!buf) {
goto ERR;
}
amt = read(fd, buf, request);
while ((amt % BLOCK_SIZE) != 0) {
if (amt < request) {
goto ERR;
}
request = request + BLOCK_SIZE;
buf = realloc(buf, request);
if (!buf) {
goto ERR;
}
amt = read(fd, buf, request);
}

return buf;

ERR:
if (buf) {
free(buf);
}
return NULL;
}
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 401
[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 - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 21.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 18-4-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[13] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[16] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[38] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.cpp.memory_leak_reallocation
Abstract
O programa redimensiona um bloco de memória alocada. Se o redimensionamento falhar, o bloco original vazará.
Explanation
Vazamentos de memória têm duas causas comuns e, às vezes, sobrepostas:

- Condições de erro e outras circunstâncias excepcionais.

- Confusão acerca de qual parte do programa é responsável pela liberação de memória.

A maioria dos vazamentos de memória resulta em problemas gerais de confiabilidade de software, mas se um invasor puder acionar intencionalmente um vazamento de memória, poderá lançar um ataque de denial of service (travando o programa) ou tirar vantagem de outro comportamento inesperado do programa resultante de uma condição de pouca memória [1].

Exemplo 1: O seguinte programa COBOL da Micro Focus vazará um bloco de memória alocada se a chamada para realloc() não redimensionar a alocação original.


CALL "malloc" USING
BY VALUE mem-size
RETURNING mem-pointer
END-CALL

ADD 1000 TO mem-size

CALL "realloc" USING
BY VALUE mem-pointer
BY VALUE mem-size
RETURNING mem-pointer
END-CALL

IF mem-pointer <> null
CALL "free" USING
BY VALUE mem-pointer
END-CALL
END-IF
References
[1] J. Whittaker and H. Thompson How to Break Software Security Addison Wesley
[2] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[3] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[4] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 2
[5] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[6] Standards Mapping - Common Weakness Enumeration CWE ID 401
[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 - Motor Industry Software Reliability Association (MISRA) C Guidelines 2012 Rule 21.3
[10] Standards Mapping - Motor Industry Software Reliability Association (MISRA) C++ Guidelines 2008 Rule 18-4-1
[11] Standards Mapping - NIST Special Publication 800-53 Revision 4 SC-5 Denial of Service Protection (P1)
[12] Standards Mapping - NIST Special Publication 800-53 Revision 5 SC-5 Denial of Service Protection
[13] Standards Mapping - OWASP Top 10 2004 A9 Application Denial of Service
[14] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-STORAGE-2
[15] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[16] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[21] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[22] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[23] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 CAT II
[24] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002400 CAT II
[25] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002400 CAT II
[26] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002400 CAT II
[27] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002400 CAT II
[28] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002400 CAT II
[29] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002400 CAT II
[30] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002400 CAT II
[31] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002400 CAT II
[34] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002400 CAT II
[35] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[36] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[37] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[38] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.controlflow.cobol.memory_leak_reallocation
Abstract
O programa pode desfazer a referência a um ponteiro nulo, lançando assim uma NullException.
Explanation
Erros de ponteiro nulo são geralmente o resultado da violação de uma ou mais das suposições do programador.

A maioria dos problemas de ponteiro nulo resulta em problemas gerais de confiabilidade de software, mas, se um invasor puder provocar intencionalmente um cancelamento de referência a um ponteiro nulo, talvez ele consiga usar a exceção resultante para se esquivar da lógica de segurança ou fazer com que o aplicativo revele informações de depuração que serão valiosas no planejamento de ataques subsequentes.

Exemplo 1: No código a seguir, o programador supõe que o sistema sempre tenha uma propriedade denominada "cmd" definida. Se um invasor puder controlar o ambiente do programa de forma que "cmd" não seja definido, o programa lançará uma exceção de ponteiro nulo quando tentar chamar o método Trim().


string cmd = null;
...
cmd = Environment.GetEnvironmentVariable("cmd");
cmd = cmd.Trim();
desc.controlflow.dotnet.null_dereference
Abstract
O programa pode desreferenciar um ponteiro nulo, causando uma falha de segmentação.
Explanation
Exceções de ponteiro nulo ocorrem geralmente quando uma ou mais suposições do programador são violadas. Existem pelo menos três faces desse problema: verificação após desreferência, desreferência após verificação e desreferência após armazenamento. Um erro de verificação após o cancelamento da referência ocorre quando um programa desfaz a referência a um ponteiro que pode ser null antes que seja verificado se ele é realmente null. Erros de desreferência após a verificação ocorrem quando um programa faz uma verificação explícita em busca de valores null, mas prossegue para desreferenciar o ponteiro quando se sabe que ele é null. Erros desse tipo são frequentemente o resultado de um erro de digitação ou de uma desatenção do programador. Um erro de desreferência após o armazenamento ocorre quando um programa define explicitamente um ponteiro como null e o desreferencia mais tarde. Esse erro é frequentemente o resultado de um programador inicializar uma variável como null quando ela é declarada.

A maioria dos problemas de ponteiro nulo resulta em problemas gerais de confiabilidade de software. Porém, se um invasor puder provocar intencionalmente uma desreferência a um ponteiro nulo, talvez ele consiga usar a exceção resultante para se esquivar da lógica de segurança a fim de formular um ataque de negação de serviço ou fazer com que o aplicativo revele informações de depuração que serão valiosas no planejamento de ataques subsequentes.

Exemplo 1: No código a seguir, o programador supõe que a variável ptr não seja NULL. Essa suposição se torna explícita quando o programador desreferencia o ponteiro. Mais tarde, essa suposição é contrariada quando o programador verifica ptr contra NULL. Se a variável ptr puder ser NULL quando for verificada na instrução if, ela também poderá ser NULL quando desreferenciada, podendo causar uma falha de segmentação.


ptr->field = val;
...
if (ptr != NULL) {
...
}
Exemplo 2: No código a seguir, o programador confirma que a variável ptr é NULL e depois a desreferencia erroneamente. Se a variável ptr for NULL quando for verificada na instrução if, ocorrerá uma desreferência null, causando assim uma falha de segmentação.


if (ptr == null) {
ptr->field = val;
...
}
Exemplo 3: No código a seguir, o programador se esquece de que a cadeia de caracteres '\0' é, na verdade, 0 ou NULL, desreferenciando assim um ponteiro nulo e provocando uma falha de segmentação.


if (ptr == '\0') {
*ptr = val;
...
}
Exemplo 4: No código a seguir, o programador define explicitamente a variável ptr como NULL. Mais tarde, o programador desreferencia ptr antes de verificar o objeto em busca de um valor null.


*ptr = NULL;
...
ptr->field = val;
...
}
desc.controlflow.cpp.null_dereference
Abstract
O programa pode desfazer a referência a um ponteiro nulo, lançando assim uma NullPointerException.
Explanation
Erros de ponteiro nulo são geralmente o resultado da violação de uma ou mais das suposições do programador.

A maioria dos problemas de ponteiro nulo resulta em problemas gerais de confiabilidade de software, mas, se um invasor puder provocar intencionalmente um cancelamento de referência a um ponteiro nulo, talvez ele consiga usar a exceção resultante para se esquivar da lógica de segurança ou fazer com que o aplicativo revele informações de depuração que serão valiosas no planejamento de ataques subsequentes.

Exemplo: No código a seguir, o programador supõe que o sistema sempre tenha uma propriedade denominada "cmd" definida. Se um invasor puder controlar o ambiente do programa de forma que "cmd" não seja definido, o programa lançará uma exceção de ponteiro nulo quando tentar chamar o método trim().


String val = null;
...
cmd = System.getProperty("cmd");
if (cmd)
val = util.translateCommand(cmd);
...
cmd = val.trim();
desc.controlflow.java.null_dereference
Abstract
O uso de funções obsoletas ou preteridas pode indicar um código negligenciado.
Explanation
Em geral, conforme as linguagens de programação evoluem, métodos acabam se tornando obsoletos pelos seguintes motivos:

- Avanços na linguagem
- Melhor compreensão de como as operações devem ser realizadas com eficiência e
segurança
- Mudanças nas convenções que regulam determinadas operações

Instruções removidas de uma linguagem são geralmente substituídas por equivalentes mais atuais que realizam a mesma tarefa de maneira um pouco diferente e, quem sabe, ainda melhor.

Em particular, o SAP ABAP evoluiu a ponto de incluir Objetos ABAP (a extensão do ABAP orientada a objetos) e de operar em um ambiente compatível com Unicode. Como resultado, uma sintaxe mais rigorosa é imposta em classes ou em programas Unicode. Construções obsoletas ainda estão disponíveis somente por questões de compatibilidade com versões mais antigas e só podem ser usadas fora de classes ou em programas não Unicode. Existem construções substitutas para todos os elementos de linguagem obsoletos que melhoram a eficiência e capacidade de leitura de programas. Muitas especificações de tipo/comprimento/memória ambíguas implícitas na sintaxe obsoleta devem ser especificadas de forma mais precisa e explícita na sintaxe mais recente. Recomenda-se adotar a sintaxe mais recente para tornar os programas mais fáceis de entender, mais robustos e mais simples de manter.


Nem todas as funções são preteridas ou substituídas porque representam um risco de segurança. No entanto, a presença de uma função obsoleta muitas vezes indica que o código circundante foi negligenciado e pode estar em mau estado de conservação. Por muito tempo, a segurança dos softwares nunca foi uma prioridade ou sequer era levada em consideração. Se o programa usar funções preteridas ou obsoletas, ele aumentará a probabilidade de haver problemas de segurança à espreita nas proximidades.
desc.semantic.abap.obsolete
Abstract
O uso de funções obsoletas ou preteridas pode indicar um código negligenciado.
Explanation
Conforme as linguagens de programação evoluem, funções acabam se tornando obsoletas pelos seguintes motivos:

- Avanços na linguagem
- Melhor compreensão de como as operações devem ser realizadas com eficiência e
segurança
- Mudanças nas convenções que regulam determinadas operações


Funções removidas de uma linguagem são geralmente substituídas por equivalentes mais atuais que realizam a mesma tarefa de maneira um pouco diferente e, quem sabe, ainda melhor.
Exemplo: O código a seguir constrói um novo objeto SqlClientPermission que regula como os usuários podem se conectar a um banco de dados. Neste exemplo, o programa transmite false como o segundo parâmetro para o construtor, que controla se os usuários têm permissão para se conectarem com senhas em branco. A transmissão de "false" para esse parâmetro indica que senhas em branco não devem ser permitidas.


...
SCP = new SqlClientPermission(pstate, false);
...


No entanto, como o objeto PermissionState transmitido como o primeiro parâmetro substitui qualquer valor transmitido ao segundo parâmetro, o construtor permite senhas em branco para conexões de banco de dados, o que contradiz o segundo argumento. Para proibir senhas em branco, o programa deve transmitir PermissionState.None ao primeiro parâmetro do construtor. Devido à ambiguidade na sua funcionalidade, a versão de dois parâmetros do construtor SqlClientPermission foi preterida a favor da versão de parâmetro único, que transmite o mesmo grau de informações sem o risco de má interpretação.

Nem todas as funções são preteridas ou substituídas porque representam um risco de segurança. No entanto, a presença de uma função obsoleta muitas vezes indica que o código circundante foi negligenciado e pode estar em mau estado de conservação. Por muito tempo, a segurança dos softwares nunca foi uma prioridade ou sequer era levada em consideração. Se o programa usar funções preteridas ou obsoletas, ele aumentará a probabilidade de haver problemas de segurança à espreita nas proximidades.
desc.semantic.dotnet.obsolete
Abstract
O uso de funções obsoletas ou preteridas pode indicar um código negligenciado.
Explanation
Conforme as linguagens de programação evoluem, funções acabam se tornando obsoletas pelos seguintes motivos:

- Avanços na linguagem.
- Melhor compreensão de como as operações devem ser realizadas de forma eficaz e segura.
- Alterações nas convenções que regem certas operações.

Funções removidas são geralmente substituídas por equivalentes mais atuais que realizam a mesma tarefa de maneira um pouco diferente e, quem sabe, ainda melhor.
Exemplo: O código a seguir usa a função preterida getpw() para verificar se a senha de texto sem formatação corresponde à senha criptografada de um usuário. Se a senha for válida, a função definirá result como 1; caso contrário, ele será definida como 0.


...
getpw(uid, pwdline);
for (i=0; i<3; i++){
cryptpw=strtok(pwdline, ":");
pwdline=0;
}
result = strcmp(crypt(plainpw,cryptpw), cryptpw) == 0;
...


Embora o código muitas vezes se comporte corretamente, usar a função getpw() pode ser uma estratégia problemática sob o ponto de vista da segurança, pois pode estourar o buffer transmitido para seu segundo parâmetro. Devido a essa vulnerabilidade, getpw() foi suplantado por getpwuid(), que executa a mesma pesquisa que getpw(), mas retorna um ponteiro para uma estrutura estaticamente alocada a fim de atenuar o risco.

Nem todas as funções são preteridas ou substituídas porque representam um risco de segurança. No entanto, a presença de uma função obsoleta muitas vezes indica que o código circundante foi negligenciado e pode estar em mau estado de conservação. Por muito tempo, a segurança dos softwares nunca foi uma prioridade ou sequer era levada em consideração. Se o programa usar funções preteridas ou obsoletas, ele aumentará a probabilidade de haver problemas de segurança à espreita nas proximidades.
desc.semantic.cpp.obsolete
Abstract
O uso de funções obsoletas ou preteridas pode indicar um código negligenciado ou o uso de uma versão antiquada do ColdFusion.
Explanation
Conforme as linguagens de programação evoluem, métodos acabam se tornando obsoletos pelos seguintes motivos:

- Avanços na linguagem
- Melhor compreensão de como as operações devem ser realizadas com eficiência e
segurança
- Mudanças nas convenções que regulam certas operações

Métodos removidos de uma linguagem são geralmente substituídos por equivalentes mais atuais que realizam a mesma tarefa de maneira um pouco diferente e, quem sabe, ainda melhor.


Nem todas as funções são preteridas ou substituídas porque representam um risco de segurança. No entanto, a presença de uma função obsoleta muitas vezes indica que o código circundante foi negligenciado e pode estar em mau estado de conservação. Por muito tempo, a segurança dos softwares nunca foi uma prioridade ou sequer era levada em consideração. Se o programa usar funções preteridas ou obsoletas, ele aumentará a probabilidade de haver problemas de segurança à espreita nas proximidades.
desc.semantic.cfml.obsolete
Abstract
O uso de funções obsoletas ou preteridas pode indicar um código negligenciado.
Explanation
Conforme as linguagens de programação evoluem, métodos acabam se tornando obsoletos pelos seguintes motivos:

- Avanços na linguagem
- Melhor compreensão de como as operações devem ser realizadas com eficiência e
segurança
- Mudanças nas convenções que regulam certas operações

Métodos removidos de uma linguagem são geralmente substituídos por equivalentes mais atuais que realizam a mesma tarefa de maneira um pouco diferente e, quem sabe, ainda melhor.
Exemplo: O código a seguir constrói um objeto de string a partir de um array de bytes e um valor que especifica os primeiros 8 bits de cada caractere Unicode de 16 bits.


...
String name = new String(nameBytes, highByte);
...


Neste exemplo, o construtor pode falhar ao converter corretamente bytes em caracteres, dependendo de qual conjunto de caracteres é usado para codificar a string representada por nameBytes. Devido à evolução dos charsets utilizados para codificar strings, este construtor foi descontinuado e substituído por um construtor que aceita como um de seus parâmetros o nome do charset usado para codificar os bytes para conversão.

Nem todas as funções são preteridas ou substituídas porque representam um risco de segurança. No entanto, a presença de uma função obsoleta muitas vezes indica que o código circundante foi negligenciado e pode estar em mau estado de conservação. Por muito tempo, a segurança dos softwares nunca foi uma prioridade ou sequer era levada em consideração. Se o programa usar funções preteridas ou obsoletas, ele aumentará a probabilidade de haver problemas de segurança à espreita nas proximidades.
References
[1] MET02-J. Do not use deprecated or obsolete classes or methods CERT
desc.semantic.java.obsolete
Abstract
O uso de funções obsoletas ou preteridas pode indicar um código negligenciado.
Explanation
Conforme as linguagens de programação evoluem, métodos acabam se tornando obsoletos pelos seguintes motivos:

- Avanços na linguagem
- Uma melhor compreensão de como as operações deveriam ser realizadas de maneira efetiva e
segura
- Mudanças nas convenções que regulam certas operações.

Métodos removidos de uma linguagem são geralmente substituídos por equivalentes mais atuais que realizam a mesma tarefa de maneira um pouco diferente e, quem sabe, ainda melhor.
Exemplo: Este código usa a stdlib Digest::HMAC, cujo uso é explicitamente desencorajado na documentação devido ao envolvimento acidental em uma versão.


require 'digest/hmac'

hmac = Digest::HMAC.new("foo", Digest::RMD160)
...
hmac.update(buf)
...


Neste exemplo, a classe Digest::HMAC foi preterida imediatamente após o envolvimento devido à inclusão acidental em uma versão. Devido à possibilidade de ela não funcionar como o esperado por causa de um código experimental e não testado apropriadamente, a utilização é extremamente desencorajada, especialmente considerando-se a relação que os HMACs têm com a funcionalidade criptográfica.

Nem todas as funções são preteridas ou substituídas porque representam um risco de segurança. No entanto, a presença de uma função obsoleta muitas vezes indica que o código circundante foi negligenciado e pode estar em mau estado de conservação. Por muito tempo, a segurança dos softwares nunca foi uma prioridade ou sequer era levada em consideração. Se o programa usar funções preteridas ou obsoletas, ele aumentará a probabilidade de haver problemas de segurança à espreita nas proximidades.
desc.structural.ruby.obsolete
Abstract
Uma função obsoleta é usada.
Explanation
Devido à natureza acelerada dos contratos inteligentes, funções e operadores podem se tornar obsoletos com versões mais recentes do compilador e usá-los pode levar a código de baixa qualidade, efeitos colaterais não intencionais e/ou erros de compilação.

Exemplo 1: O código a seguir obtém o hash do bloco atual usando block.blockhash(), que está obsoleto desde a versão 0.5.0 do compilador Solidity.


bytes32 blockhash = block.blockhash(0);
desc.structural.solidity.swc111
Abstract
A função é obsoleta e não pode garantir que um ponteiro seja válido ou que o uso da memória referenciada seja seguro.
Explanation
Há vários motivos para não se usar a classe de funções IsBadXXXPtr(). Essas funções:
1) Não são "thread-safe".
2) Estão frequentemente envolvidas em travamentos causados por sua sondagem de endereços de memória inválidos.
3) São incorretamente designadas como funções que realizam um tratamento impróprio de erros durante condições de exceção.

Exemplo: O código a seguir usa IsBadWritePtr() em uma tentativa de impedir gravações de memória inválidas.

if (IsBadWritePtr(ptr, length))
{
[handle error]
}


Os programadores costumam usar essas funções com a pretensão de que irão detectar casos de exceção, mas elas geralmente causam mais problemas do que os corrigem.
References
[1] Raymond Chen IsBadXxxPtr should really be called CrashProgramRandomly
[2] IsBadWritePtr Function Microsoft
[3] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[4] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 2
[5] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[6] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[7] Standards Mapping - Common Weakness Enumeration CWE ID 730
[8] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001094
[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 Top 10 2004 A9 Application Denial of Service
[12] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.9
[13] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP6080 CAT II
[14] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP6080 CAT II
[15] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP6080 CAT II
[16] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP6080 CAT II
[17] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP6080 CAT II
[18] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP6080 CAT II
[19] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP6080 CAT II
[20] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002400 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 5.1 APSC-DV-002400 CAT II
[32] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002400 CAT II
[33] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002400 CAT II
[34] Standards Mapping - Web Application Security Consortium Version 2.00 Denial of Service (WASC-10)
[35] Standards Mapping - Web Application Security Consortium 24 + 2 Denial of Service
desc.semantic.cpp.obsolete_inadequate_pointer_validation
Abstract
A classe contém um campo e um método com o mesmo nome.
Explanation
É confuso ter um campo membro e um método com o mesmo nome. Isso torna mais fácil para um programador chamar o método acidentalmente ao tentar acessar o campo, ou vice-versa.

Exemplo 1:

public class Totaller {
private int total;
public int total() {
...
}
}
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 398, CWE ID 710
[6] Standards Mapping - Smart Contract Weakness Classification SWC-119
desc.structural.java.poor_style_confusing_naming.member_and_method
Abstract
O contrato usa uma variável sombreada que é ambígua e propensa a uso indevido.
Explanation
O Solidity permite que os desenvolvedores declarem variáveis de estado de forma ambígua. Isso significa que mesmo que duas variáveis diferentes em dois contextos diferentes possam ser declaradas com o mesmo nome, usá-las poderá levar à confusão e ao uso indevido.

Isso pode acontecer tanto no nível da função quanto no nível da herança. Por exemplo, se Contrato1 declara var1 e herda de Contrato2, que também declara uma variável chamada var1, então a variável será ambígua e poderá ser facilmente confundida entre si posteriormente na execução do contrato inteligente.

Exemplo 1: O código a seguir usa herança e declara uma variável de estado com o mesmo nome em ambos os contratos inteligentes. Pode ser difícil determinar qual é o hardcap real da venda do token.


contract Tokensale {
uint hardcap = 10000 ether;

function Tokensale() { }

function fetchCap() public constant returns(uint) {
return hardcap;
}
}

contract Presale is Tokensale {
uint hardcap = 1000 ether;

function Presale() Tokensale() { }
}
References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 1
[2] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5
[3] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[4] Standards Mapping - CIS Google Kubernetes Engine Benchmark normal
[5] Standards Mapping - Common Weakness Enumeration CWE ID 398, CWE ID 710
[6] Standards Mapping - Smart Contract Weakness Classification SWC-119
desc.structural.solidity.swc119