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.

2 itens encontrados
Vulnerabilidades
Abstract
As operações de gravação Open SQL diretas são uma prática imprópria e devem ser evitadas.
Explanation
Em geral, operações de gravação Open SQL diretas (Insert/Update/Modify/Delete) são uma prática imprópria e devem ser evitadas. Elas prejudicam a integridade e a segurança do sistema e não devem ser permitidas.



As operações de gravação Open SQL diretas também são propensas a erros e podem provocar o comportamento inesperado do sistema. Alguns dos problemas que devem ser observados no SAP incluem:

- A SAP recomenda o uso de técnicas de "agrupamento de atualizações" para garantir a integridade dos dados em uma LUW (unidade lógica de trabalho) SAP que pode propagar várias LUWs de banco de dados. Modificações diretas em entradas de tabelas sem o agrupamento de atualizações podem deixar a transação SAP em um estado inconsistente.

- Operações de gravação Open SQL diretas apenas definem bloqueios no nível do banco de dados e ignoram os bloqueios de aplicativos SAP. Isso pode resultar em deadlocks e dados corrompidos.

- Operações de gravação Open SQL diretas ignoram verificações de autorização SAP dentro do programa aplicativo.

- Quando mecanismos padrão são utilizados para gravar entradas de tabela, editar verificações e realizar trilhas de auditoria, todas as atualizações dependentes (como documentos de alteração, por exemplo) são realizadas corretamente. Este não é o caso quando operações de gravação Open SQL diretas são utilizadas.

References
[1] Standards Mapping - Common Weakness Enumeration CWE ID 662
[2] Standards Mapping - Common Weakness Enumeration Top 25 2022 [22] CWE ID 362
[3] Standards Mapping - Common Weakness Enumeration Top 25 2023 [21] CWE ID 362
[4] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002235
[5] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[6] Standards Mapping - NIST Special Publication 800-53 Revision 4 AC-6 Least Privilege (P1)
[7] Standards Mapping - NIST Special Publication 800-53 Revision 5 AC-6 Least Privilege
[8] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000500 CAT II
[9] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000500 CAT II
[10] Standards Mapping - Security Technical Implementation Guide Version 6.1 APSC-DV-000500 CAT II
desc.structural.abap.sql_bad_practices_direct_update
Abstract
Os identificadores sem esquemas não devem ser usados nos pacotes de direitos do chamador.
Explanation
Nos direitos de um chamador, ou no pacote AUTHID CURRENT_USER, os identificadores são primeiro resolvidos de acordo com o esquema atual do usuário. Isso pode causar um comportamento inesperado se o definidor do código não disser explicitamente a qual esquema um identificador pertence.

Exemplo 1: O código a seguir verifica se o usuário tem permissões para executar uma ação ao buscar o usuário em uma tabela de permissões. A maioria dos usuários terá apenas o acesso de leitura a SYS.PERMISSIONS e não poderá modificar as permissões definidas.


CREATE or REPLACE FUNCTION check_permissions(
p_name IN VARCHAR2, p_action IN VARCHAR2)
RETURN BOOLEAN
AUTHID CURRENT_USER
IS
r_count NUMBER;
perm BOOLEAN := FALSE;
BEGIN
SELECT count(*) INTO r_count FROM PERMISSIONS
WHERE name = p_name AND action = p_action;
IF r_count > 0 THEN
perm := TRUE;
END IF;
RETURN perm;
END check_permissions


Se o usuário que está chamando a função check_permissions definir uma tabela de PERMISSIONS no esquema dele, o banco de dados resolverá o identificador para consultar a tabela local. O usuário teria acesso de gravação à nova tabela e poderia modificá-la para obter permissões que não teria de outra maneira.
References
[1] Oracle Oracle Database PL/SQL Language Reference
[2] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
desc.structural.sql.sql_bad_practices_underspecified_identifier