Reino: API Abuse

Un API es un contrato entre un autor de llamada y un receptor de llamada. Las formas de abuso de API más comunes los produce el autor de llamada cuando no consigue atender su fin de este contrato. Por ejemplo, si un programa no consigue llamar chdir() después de llamar chroot(), se viola el contrato que especifica cómo cambiar el directorio de origen activo de una forma segura. Otro buen ejemplo de un abuso de manual es esperar que el receptor devuelva una información de DNS de confianza al autor de llamada. En este caso, el autor de llamada abusa el API del receptor haciendo determinadas suposiciones sobre su comportamiento (que el valor de retorno se puede usar con fines de autenticación). También se puede violar el contrato entre el autor de llamada y el receptor desde el otro lado. Por ejemplo, si un codificador envía SecureRandom y devuelve un valor no aleatorio, se viola el contrato.

SQL Bad Practices: Direct Update

Abstract
No se recomiendan las operaciones de escritura Direct Open SQL, por lo que se deben evitar.
Explanation
Las operaciones de escritura de Direct Open SQL (Insertar/Actualizar/Modificar/Eliminar) son, en general, poco recomendables y deben evitarse. porque minan la integridad y seguridad del sistema.



Además, las operaciones de escritura de Direct Open SQL son propensas a errores y pueden provocar comportamientos inesperados del sistema. Algunos de los problemas a los que se debe prestar atención en SAP son:

- SAP recomienda el uso de las técnicas "update bundling" (unión de actualizaciones) para asegurar la integridad de los datos dentro de una LUW (unidad lógica de trabajo) que tal vez abarque varias LUW de bases de datos. Las modificaciones directas en las entradas de tabla sin "update bundling" (unión de actualizaciones) pueden dejar la transacción SAP en un estado incoherente.

- Las operaciones de escritura de Direct Open SQL solo establecen los bloqueos de nivel de base de datos y omiten los bloqueos de la aplicación SAP. Esto puede dar lugar a interbloqueos y datos dañados.

- Las operaciones de escritura de Direct Open SQL omiten las comprobaciones de autorización SAP dentro del programa de aplicación.

- Cuando se usan mecanismos estándar para escribir entradas de tablas, comprobaciones de edición, pistas de auditoría, actualizaciones de dependientes (como cambiar documentos, por ejemplo) se ejecutan todas correctamente. Esto no sucede así cuando se utilizan operaciones de escritura Direct Open SQL.

References
[1] Standards Mapping - CIS Azure Kubernetes Service Benchmark 4
[2] Standards Mapping - CIS Microsoft Azure Foundations Benchmark partial
[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 integrity
[6] Standards Mapping - Common Weakness Enumeration CWE ID 662
[7] Standards Mapping - Common Weakness Enumeration Top 25 2022 [22] CWE ID 362
[8] Standards Mapping - Common Weakness Enumeration Top 25 2023 [21] CWE ID 362
[9] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-002235
[10] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[11] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-000500 CAT II
[12] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-000500 CAT II
desc.structural.abap.sql_bad_practices_direct_update