Reino: Input Validation and Representation
Los problemas de validación y representación de entradas están causados por metacaracteres, codificaciones alternativas y representaciones numéricas. Los problemas de seguridad surgen de entradas en las que se confía. Estos problemas incluyen: «desbordamientos de búfer», ataques de «scripts de sitios», "SQL injection" y muchas otras acciones.
SQL Injection: Persistence
Abstract
La creación de una instrucción SQL dinámica con una entrada procedente de un origen que no es de confianza podría permitir a un usuario malintencionado modificar el significado de la instrucción o ejecutar comandos SQL arbitrarios.
Explanation
Se producen errores de SQL Injection cuando:
1. Los datos entran en un programa desde un origen que no es de confianza.
En este caso, Fortify Static Code Analyzer no pudo determinar si el origen de los datos era de confianza.
2. Los datos se utilizan para crear dinámicamente una consulta SQL.
Ejemplo 1: el siguiente código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.
La consulta intenta ejecutar el código siguiente:
Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si
La adición de la condición
Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla
Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el
Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.
Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general podría seguir siendo eficaz mediante un truco similar al que se utilizó en el
Algunos piensan que en el mundo de las plataformas móviles, las vulnerabilidades de las aplicaciones web clásicas como la SQL Injection no tienen ningún sentido: ¿por qué se atacaría a sí mismo un usuario? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.
Ejemplo 3: el siguiente código adapta el
Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:
- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados
Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.
Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados podrán evitar algunos ataques, pero no harán que la aplicación quede protegida frente a ataques de SQL Injection.
1. Los datos entran en un programa desde un origen que no es de confianza.
En este caso, Fortify Static Code Analyzer no pudo determinar si el origen de los datos era de confianza.
2. Los datos se utilizan para crear dinámicamente una consulta SQL.
Ejemplo 1: el siguiente código crea y ejecuta una consulta SQL de forma dinámica que busca elementos que coincidan con un nombre especificado. La consulta restringe los elementos mostrados a aquellos donde el propietario coincide con el nombre de usuario del usuario actualmente autenticado.
...
String userName = ctx.getAuthenticatedUserName();
String itemName = request.getParameter("itemName");
String query = "SELECT * FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ itemName + "'";
ResultSet rs = stmt.execute(query);
...
La consulta intenta ejecutar el código siguiente:
SELECT * FROM items
WHERE owner = <userName>
AND itemname = <itemName>;
Sin embargo, dado que la consulta se crea dinámicamente mediante la concatenación de una cadena de consulta de base constante y una cadena de entrada del usuario, la consulta solo funciona correctamente si
itemName
no contiene un carácter de comilla simple. Si un usuario malintencionado con el nombre de usuario wiley
introduce la cadena "name' OR 'a'='a
" para itemName
, la consulta se convertirá en lo siguiente:
SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name' OR 'a'='a';
La adición de la condición
OR 'a'='a'
hace que la cláusula where siempre se evalúe como true, por lo que lógicamente la consulta pasará a ser equivalente a la consulta más simple:
SELECT * FROM items;
Esta simplificación de la consulta permite que el usuario malintencionado pueda eludir el requisito de que la consulta solo devuelva elementos que pertenecen al usuario autenticado. Ahora, la consulta devuelve todas las entradas almacenadas en la tabla
items
, independientemente del propietario especificado.Ejemplo 2: En este ejemplo se examinan los efectos de un valor malintencionado distinto que pasó a la consulta creada y ejecutada en el
Example 1
. Si un usuario malintencionado con el nombre de usuario wiley
introduce la cadena "name'; DELETE FROM items; --
" para itemName
, la consulta se convertirá en las dos consultas siguientes:
SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';
DELETE FROM items;
--'
Muchos servidores de base de datos, incluido Microsoft(R) SQL Server 2000, permiten que se ejecuten al mismo tiempo varias instrucciones de SQL separadas por punto y coma. Mientras que esta cadena de ataque da como resultado un error en Oracle y otros servidores de base de datos que no permiten la ejecución por lotes de instrucciones separadas por punto y coma, en las bases de datos que permiten la ejecución por lotes, este tipo de ataque permite al usuario malintencionado ejecutar comandos arbitrarios en la base de datos.
Tenga en cuenta el par final de guiones (--), que indican a la mayoría de los servidores de base de datos que el resto de la instrucción se debe tratar como un comentario y no ejecutarse [4]. En este caso el carácter de comentario sirve para quitar la comilla simple final de la consulta modificada. En una base de datos donde no se permite que los comentarios se utilicen de esta manera, el ataque general podría seguir siendo eficaz mediante un truco similar al que se utilizó en el
Example 1
. Si un usuario malintencionado escribe la cadena "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a
", se crearán las tres instrucciones válidas siguientes:
SELECT * FROM items
WHERE owner = 'wiley'
AND itemname = 'name';
DELETE FROM items;
SELECT * FROM items WHERE 'a'='a';
Algunos piensan que en el mundo de las plataformas móviles, las vulnerabilidades de las aplicaciones web clásicas como la SQL Injection no tienen ningún sentido: ¿por qué se atacaría a sí mismo un usuario? Sin embargo, tenga en cuenta que la esencia de las plataformas móviles consiste en aplicaciones que se descargan desde varias fuentes y se ejecutan junto con otras en el mismo dispositivo. La probabilidad de ejecutar un malware junto a una aplicación de banca es bastante alta, de modo que se necesita expandir la superficie expuesta a ataques de las aplicaciones móviles para que incluyan las comunicaciones entre procesos.
Ejemplo 3: el siguiente código adapta el
Example 1
a la plataforma Android.
...
PasswordAuthentication pa = authenticator.getPasswordAuthentication();
String userName = pa.getUserName();
String itemName = this.getIntent().getExtras().getString("itemName");
String query = "SELECT * FROM items WHERE owner = '"
+ userName + "' AND itemname = '"
+ itemName + "'";
SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
Cursor c = db.rawQuery(query, null);
...
Un enfoque tradicional para la prevención de ataques de SQL Injection es tratarlos como un problema de validación de entradas y aceptar solo los caracteres de una lista de valores seguros permitidos, o bien identificar y omitir una lista de valores potencialmente malintencionados (lista de rechazados). La comprobación de una lista de permitidos puede ser un medio muy eficaz para aplicar reglas estrictas de validación de entradas, pero las instrucciones SQL parametrizadas requieren menos mantenimiento y pueden ofrecer más garantías con respecto a la seguridad. Como casi siempre, implementar una lista de rechazados presenta enormes lagunas que la hacen ineficaz para impedir los ataques de SQL Injection. Por ejemplo, los atacantes podrían:
- Elegir como destino campos que no están entre comillas
- Buscar formas de omitir la necesidad de determinados metacaracteres de escape
- Utilizar procedimientos almacenados para ocultar los metacaracteres inyectados
Eludir manualmente los caracteres de entrada de las consultas SQL puede ayudar, pero no hará que la aplicación sea segura frente a los ataques de SQL Injection.
Otra solución que comúnmente se propone para afrontar los ataques de SQL Injection consiste en utilizar los procedimientos almacenados. Aunque los procedimientos almacenados evitan algunos tipos de ataques de SQL Injection, no pueden proteger frente a muchos otros. Los procedimientos almacenados normalmente ayudan a prevenir los ataques de SQL Injection al limitar los tipos de instrucciones que se pueden pasar a sus parámetros. Sin embargo, existen muchas formas de limitaciones y muchas instrucciones interesantes que pueden pasarse a los procedimientos almacenados. De nuevo, los procedimientos almacenados podrán evitar algunos ataques, pero no harán que la aplicación quede protegida frente a ataques de SQL Injection.
References
[1] S. J. Friedl SQL Injection Attacks by Example
[2] P. Litwin Stop SQL Injection Attacks Before They Stop You MSDN Magazine
[3] P. Finnigan SQL Injection and Oracle, Part One Security Focus
[4] M. Howard, D. LeBlanc Writing Secure Code, Second Edition Microsoft Press
[5] IDS00-J. Prevent SQL Injection CERT
[6] INJECT-2: Avoid dynamic SQL Oracle
[7] Standards Mapping - CIS Azure Kubernetes Service Benchmark 5.0
[8] Standards Mapping - CIS Microsoft Azure Foundations Benchmark complete
[9] Standards Mapping - CIS Amazon Elastic Kubernetes Service Benchmark 5.0
[10] Standards Mapping - CIS Amazon Web Services Foundations Benchmark 1
[11] Standards Mapping - CIS Google Kubernetes Engine Benchmark integrity
[12] Standards Mapping - CIS Kubernetes Benchmark partial
[13] Standards Mapping - Common Weakness Enumeration CWE ID 89
[14] Standards Mapping - Common Weakness Enumeration Top 25 2019 [6] CWE ID 089
[15] Standards Mapping - Common Weakness Enumeration Top 25 2020 [6] CWE ID 089
[16] Standards Mapping - Common Weakness Enumeration Top 25 2021 [6] CWE ID 089
[17] Standards Mapping - Common Weakness Enumeration Top 25 2022 [3] CWE ID 089
[18] Standards Mapping - Common Weakness Enumeration Top 25 2023 [3] CWE ID 089
[19] Standards Mapping - DISA Control Correlation Identifier Version 2 CCI-001310, CCI-002754
[20] Standards Mapping - FIPS200 SI
[21] Standards Mapping - General Data Protection Regulation (GDPR) Indirect Access to Sensitive Data
[22] Standards Mapping - NIST Special Publication 800-53 Revision 4 SI-10 Information Input Validation (P1)
[23] Standards Mapping - NIST Special Publication 800-53 Revision 5 SI-10 Information Input Validation
[24] Standards Mapping - OWASP Top 10 2004 A6 Injection Flaws
[25] Standards Mapping - OWASP Top 10 2007 A2 Injection Flaws
[26] Standards Mapping - OWASP Top 10 2010 A1 Injection
[27] Standards Mapping - OWASP Top 10 2013 A1 Injection
[28] Standards Mapping - OWASP Top 10 2017 A1 Injection
[29] Standards Mapping - OWASP Top 10 2021 A03 Injection
[30] Standards Mapping - OWASP Application Security Verification Standard 4.0 5.3.4 Output Encoding and Injection Prevention Requirements (L1 L2 L3), 5.3.5 Output Encoding and Injection Prevention Requirements (L1 L2 L3)
[31] Standards Mapping - OWASP Mobile 2014 M1 Weak Server Side Controls
[32] Standards Mapping - OWASP Mobile Application Security Verification Standard 2.0 MASVS-CODE-4, MASVS-PLATFORM-1
[33] Standards Mapping - Payment Card Industry Data Security Standard Version 1.1 Requirement 6.5.6
[34] Standards Mapping - Payment Card Industry Data Security Standard Version 1.2 Requirement 6.3.1.1, Requirement 6.5.2
[35] Standards Mapping - Payment Card Industry Data Security Standard Version 2.0 Requirement 6.5.1
[36] Standards Mapping - Payment Card Industry Data Security Standard Version 3.0 Requirement 6.5.1
[37] Standards Mapping - Payment Card Industry Data Security Standard Version 3.1 Requirement 6.5.1
[38] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2 Requirement 6.5.1
[39] Standards Mapping - Payment Card Industry Data Security Standard Version 3.2.1 Requirement 6.5.1
[40] Standards Mapping - Payment Card Industry Data Security Standard Version 4.0 Requirement 6.2.4
[41] Standards Mapping - Payment Card Industry Software Security Framework 1.0 Control Objective 4.2 - Critical Asset Protection
[42] Standards Mapping - Payment Card Industry Software Security Framework 1.1 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation
[43] Standards Mapping - Payment Card Industry Software Security Framework 1.2 Control Objective 4.2 - Critical Asset Protection, Control Objective B.3.1 - Terminal Software Attack Mitigation, Control Objective B.3.1.1 - Terminal Software Attack Mitigation, Control Objective C.3.2 - Web Software Attack Mitigation
[44] Standards Mapping - SANS Top 25 2009 Insecure Interaction - CWE ID 089
[45] Standards Mapping - SANS Top 25 2010 Insecure Interaction - CWE ID 089
[46] Standards Mapping - SANS Top 25 2011 Insecure Interaction - CWE ID 089
[47] Standards Mapping - Security Technical Implementation Guide Version 3.1 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[48] Standards Mapping - Security Technical Implementation Guide Version 3.4 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[49] Standards Mapping - Security Technical Implementation Guide Version 3.5 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[50] Standards Mapping - Security Technical Implementation Guide Version 3.6 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[51] Standards Mapping - Security Technical Implementation Guide Version 3.7 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[52] Standards Mapping - Security Technical Implementation Guide Version 3.9 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[53] Standards Mapping - Security Technical Implementation Guide Version 3.10 APP3510 CAT I, APP3540.1 CAT I, APP3540.3 CAT II
[54] Standards Mapping - Security Technical Implementation Guide Version 4.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[55] Standards Mapping - Security Technical Implementation Guide Version 4.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[56] Standards Mapping - Security Technical Implementation Guide Version 4.3 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[57] Standards Mapping - Security Technical Implementation Guide Version 4.4 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[58] Standards Mapping - Security Technical Implementation Guide Version 4.5 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[59] Standards Mapping - Security Technical Implementation Guide Version 4.6 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[60] Standards Mapping - Security Technical Implementation Guide Version 4.7 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[61] Standards Mapping - Security Technical Implementation Guide Version 4.8 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[62] Standards Mapping - Security Technical Implementation Guide Version 4.9 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[63] Standards Mapping - Security Technical Implementation Guide Version 4.10 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[64] Standards Mapping - Security Technical Implementation Guide Version 4.11 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[65] Standards Mapping - Security Technical Implementation Guide Version 5.1 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[66] Standards Mapping - Security Technical Implementation Guide Version 5.2 APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[67] Standards Mapping - Security Technical Implementation Guide Version 5.3 APSC-DV-002530 CAT II, APSC-DV-002540 CAT I, APSC-DV-002560 CAT I
[68] Standards Mapping - Web Application Security Consortium Version 2.00 SQL Injection (WASC-19)
[69] Standards Mapping - Web Application Security Consortium 24 + 2 SQL Injection
desc.semantic.java.sql_injection_persistence