CWE-89

El producto construye la totalidad o parte de un comando SQL utilizando entradas influenciadas externamente provenientes de un componente ascendente, pero no neutraliza o neutraliza incorrectamente elementos especiales que podrían modificar el comando SQL previsto cuando se envía a un componente descendente. Sin una eliminación o un entrecomillado suficiente de la sintaxis SQL en las entradas controlables por el usuario, la consulta SQL generada puede hacer que esas entradas se interpreten como SQL en lugar de como datos de usuario ordinarios.

Consecuencias comunes

• Confidencialidad, Integridad, Disponibilidad → Ejecución de código o comandos no autorizados
• Confidencialidad → Lectura de datos de la aplicación
• Autenticación → Obtención de privilegios o suplantación de identidad, Elusión del mecanismo de protección
• Control de acceso → Elusión del mecanismo de protección
• Integridad → Modificación de datos de la aplicación

Mitigaciones

• Arquitectura y diseño: Utilice una biblioteca o marco de trabajo verificado que no permita que esta debilidad ocurra o que proporcione construcciones que faciliten evitarla [REF-1482]. Por ejemplo, considere usar capas de persistencia como Hibernate o Enterprise Java Beans, que pueden proporcionar una protección significativa contra la inyección SQL si se usan correctamente.
• Arquitectura y diseño: Si están disponibles, utilice mecanismos estructurados que impongan automáticamente la separación entre datos y código. Estos mecanismos pueden ser capaces de proporcionar el entrecomillado, la codificación y la validación pertinentes de forma automática, en lugar de depender de que el desarrollador proporcione esta capacidad en cada punto donde se genera la salida. Procese
• Arquitectura y diseño, Operación: Ejecute su código utilizando los privilegios más bajos que se requieran para llevar a cabo las tareas necesarias [REF-76]. Si es posible, cree cuentas aisladas con privilegios limitados que se usen únicamente para una sola tarea. De esa manera, un ataque exitoso no dará de inmediato al atacante acceso al resto del software o de su entorno. Por ejemplo, las aplicac
• Arquitectura y diseño: Para cualquier verificación de seguridad que se realice en el lado del cliente, asegúrese de que estas verificaciones se dupliquen en el lado del servidor, a fin de evitar CWE-602. Los atacantes pueden eludir las verificaciones del lado del cliente modificando los valores después de que se hayan realizado las verificaciones, o cambiando el cliente para eliminar por completo
• Implementación: Si bien es arriesgado usar cadenas de consulta, código o comandos generados dinámicamente que mezclan control y datos, a veces puede ser inevitable. Entrecomille adecuadamente los argumentos y escape cualquier carácter especial dentro de esos argumentos. El enfoque más conservador es escapar o filtrar todos los caracteres que no pasen una lista de permitidos extremadamente estricta
• Implementación: Suponga que toda entrada es maliciosa. Utilice una estrategia de validación de entradas de tipo "aceptar lo que se sabe que es válido", es decir, use una lista de entradas aceptables que se ajusten estrictamente a las especificaciones. Rechace cualquier entrada que no se ajuste estrictamente a las especificaciones, o transfórmela en algo que sí lo haga. Al realizar la validación de