Apartado 2.2.2 Inyección de Código

2.2.
2 Inyección de código
Inyección de código (1)
• Cuando una aplicación interactúa con otra, tienen que utilizar algún tipo de
lenguaje, formato o protocolo de intercambio de información.
• Ese lenguaje de intercambio se suele combinar con datos que proceden del
usuario (por ejemplo, datos introducidos a través de un campo de texto de un
formulario) para componer un mensaje de forma dinámica.
• Las vulnerabilidades de inyección de código utilizan como datos de entrada
determinadas palabras o tokens especiales (palabras reservadas) en esos
lenguajes.
• Cuando esos datos no se validan de forma correcta para tratar las palabras
especiales, una entrada de usuario malintencionada puede intentar cambiar la
semántica del mensaje original, con el objetivo de causar algún daño.
• Así pues, es posible encontrar inyección de código en todos los lenguajes o
formatos de intercambio de información utilizados en las aplicaciones software.
2
• Por su importancia, este riesgo se encuentra en posiciones
relevantes en todas las versiones de informe OWASP Top 10.
- OWASP Top 10 2013: 1ª posición.
3
• Ejemplos de lenguajes o protocolos en los que se puede encontrar
inyección de código:
- Base de datos (SQL o NoSQL).
- Ficheros de log.
- Cabeceras HTTP.
- Cabeceras SMTP.
- Comandos del sistema operativo.
- LDAP.
- XML y XPath.
4
Inyección de SQL (1)
• Se produce inyección de código SQL (SQL Injection) cuando:
- Los datos de entrada proporcionados por el usuario, se utilizan para componer una
consulta SQL.
- En esos datos se incluye alguna palabra especial de SQL (token), por ejemplo,
comillas o punto y coma.
- El uso de esas palabras reservadas permite cambiar la semántica de la consulta de tal
manera que lo que se ejecuta contra la base de datos tiene una naturaleza
completamente diferente a lo que se pretendía en un principio.
- Incluso es posible ejecutar consultas adicionales de borrado o modificación de datos.
• Las consecuencias de una vulnerabilidad de inyección de SQL pueden ser
muy graves. La primera de ellas podría ser la revelación de información.
5
1. La consulta se genera de forma dinámica concatenando cadenas de texto.
2. Los datos de entrada incluyen caracteres especiales de SQL.
3. La consulta que se ejecuta tiene una semántica diferente. En este ejemplo, la consulta original pretende
autenticar al usuario, mientras que la consulta que finalmente se ejecuta ignora la contraseña.
3
6
• El siguiente formulario permite modificar los datos de un usuario y para ello
previamente se obtienen los valores actuales (email, contraseña y nombre) en la
siguiente consulta a la base de datos.
7
• La consulta que obtiene la información del usuario se ve afectada por inyección
de SQL como se verá en los siguientes ejemplos.
• En el siguiente ejemplo, la consulta no realiza una búsqueda por el email del
usuario sino que devuelve información de una cuenta diferente.
• El siguiente ejemplo, se podría utilizar para obtener la contraseña del usuario a

través de un ataque de fuerza bruta, basado en un diccionario de contraseñas
frecuentes.
8
• A través de inyección de SQL también se pueden realizar modificaciones en la
base de datos.
• Por ejemplo, se podría ejecutar el borrado completo de toda una tabla.
• Y también es posible insertar nuevas tuplas. En el siguiente ejemplo, se ejecuta la

creación de un nuevo usuario.
9
• También se pueden ejecutar modificaciones puntuales de algún
registro de la base de datos, en este ejemplo, se modifica el email de
un usuario.
• Este ejemplo, con una modificación más sutil de los datos, podría
llegar a ser más difícil de detectar.
10
• Otras técnicas de inyección de SQL intentan explotar características o sintaxis
específica de algún gestor de base de datos concreto.
• Para ello, es necesario identificar qué gestor de base de datos almacena la
información (database fingerprint) y esto se puede conseguir analizando los
mensajes de error.
• Es importante que estos mensajes nunca sean visibles para no revelar
información.
11
• Inyección de SQL a ciegas (Blind SQL Injection) es un tipo de
inyección en la que el atacante genera consultas booleanas a través
de las cuales es posible descubrir información de forma progresiva.
• Se suele combinar con ataques de fuerza bruta basados en
diccionarios e incluso se puede explotar en aplicaciones que no
muestran los mensajes de error que provienen de la base de datos.
• Ejercicio: obtener información sobre la base de datos del siguiente
sitio web, usando la técnica de inyección de SQL a ciegas:
http://testphp.vulnweb.com
12
“cat=2”
Este es el escenario normal en el que se especifica un valor
numérico para el parámetro “cat”.
La aplicación muestra el contenido de la categoría
seleccionada.
“cat=2 and”
En esta caso, se añade la palabra “and” que está reservada
en SQL.
La aplicación muestra un error de sintaxis, lo que significa
que ha sido posible generar una consulta inválida y por lo
tanto, la aplicación puede ser vulnerable.
Adicionalmente, el mensaje de error muestra que el gestor
de bases de datos es MySQL.
13
“cat=2 and 1=1”
En este caso, no se produce error y se muestran resultados
válidos.
Por lo tanto, la consulta SQL que se está ejecutando podría
ser similar a la siguiente:
SELECT * FROM categories WHERE
categoryId=2 and 1=1
“cat=2 and 1=2”

En este caso, no se muestra ningún error pero tampoco se
muestran resultados.
Por lo tanto, la consulta es sintácticamente correcta pero
evalúa a false.
14
“cat=2 and substring(@@version,1,1)=4”
Con esta consulta que evalúa a false, el atacante
ha conseguido averiguar que la versión de la base
de datos NO es la versión 4.x
“cat=2 and (SELECT 1 from users)=1”

Con esta consulta, que evalúa a true, el atacante
ha conseguido averiguar que la tabla de usuarios
se llama “users”
15
Inyección de SQL (12): prevención
• Para prevenir los ataques de inyección de SQL, la técnica más efectiva
consiste en utilizar consultas parametrizadas (Prepared Statements).
• Con el uso de consultas parametrizadas, se evita la construcción de la
consulta de forma manual a través de la concatenación de cadenas de
texto.
16
• Las consultas parametrizadas se encargan de formatear los datos de
entrada para generar consultas SQL válidas en un gestor de base de
datos concreto.
• Como parte de este formateado de los datos de entrada, también se
realiza el escapado de las palabras y caracteres reservados en el
dialecto SQL de la base de datos concreta.
• En la plataforma Java, cada implementación específica del driver
JDBC, es la que se encarga de formatear los parámetros de las
consultas y por lo tanto, de escapar los datos que provienen de las
entradas del usuario.
17
• El siguiente ejemplo de código muestra el funcionamiento de la clase
PreparedStatement. Los parámetros se representan con ? y se pueden
establecer con los métodos set (setString, setDate, etc.).
• La consulta que se ejecuta contra la base de datos contiene los

argumentos formateados.
18
• Si los parámetros de entrada contienen caracteres reservados en SQL,
el driver JDBC se encarga de escaparlos.
• De tal forma que la consulta que se genera no se ve afectada por

inyección de SQL. En el ejemplo, la comilla simple ha sido escapada
con otra comilla simple.
19
• En caso de utilizar JPA (Java Persistence API), el formateado de los
parámetros de entrada se hace de una forma muy similar.
• Más información en el siguiente enlace:

https://docs.oracle.com/javaee/6/tutorial/doc/bnbrg.html
20
• Los PreparedStatements permiten establecer parámetros cuando se
trata de valores literales (valores de columnas).
• Pero no permiten establecer parámetros de consulta cuando se trata
de identificadores (nombres de tablas y de columnas). Cabe destacar
que la mayor parte de las aplicaciones no tienen esta necesidad.
21
• En el caso de no poder usar consultas parametrizadas, la técnica
recomendada son las listas blancas de valores válidos.
• Por medio de esta técnica, el conjunto de valores válidos está
perfectamente acotado y el sistema rechaza cualquier otro dato de entrada
que no esté incluido en ese conjunto.
• En el siguiente ejemplo ilustra como parametrizar el nombre de la tabla a
través de una lista de valores válidos.
Fuente: owasp.org 22
• La técnica de último recurso que habría que utilizar en el caso de que no
puedan aplicarse ninguna de las anteriores, consiste en escapar de forma
manual todos los datos que provienen de entradas del usuario.
• Las reglas de escapado son diferentes en cada base de datos.
Oracle:
http://www.orafaq.com/wiki/SQL_FAQ#How_does_one_escape_special_characters_whe
n_writing_SQL_queries.3F
SQL Server:
https://blogs.msdn.microsoft.com/raulga/2007/01/04/dynamic-sql-sql-injection/
MySQL:
https://dev.mysql.com/doc/refman/5.7/en/string-literals.html
23
Inyección de SQL (20): referencias
• Esta vulnerabilidad tiene su propia entrada en la lista CWE.
CWE-89: Improper Neutralization of Special Elements used in an SQL

Command ('SQL Injection').
• Dentro de la plataforma Java, también hay otra variante de inyección

de SQL específica para la librería Hibernate:
CWE-564: SQL Injection: Hibernate.
24
• Ejemplos de patrones de ataque registrados en el CAPEC y
relacionados con la vulnerabilidad de inyección de SQL son los
siguientes:
- CAPEC-66: SQL Injection

- CAPEC-7: Blind SQL Injection
- CAPEC-110: SQL Injection through SOAP Parameter Tampering
25
• Hasta septiembre de 2023, en el CVE había registradas más de 10000
vulnerabilidades relacionadas con inyección de SQL (CWE-89).
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overv
iew&search_type=all&cwe_id=CWE-89
• Y sólo desde enero a abril de 2023 se registraron un total de 792

vulnerabilidades relacionadas con inyección de SQL.
https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&
search_type=all&cwe_id=CWE-
89&isCpeNameSearch=false&pub_start_date=01%2F01%2F2023&pub_end_date=05%2F01%2F2023
26
• La empresa Veracode, uno de los líderes mundiales en seguridad, ha
encontrado vulnerabilidades de inyección de SQL en el 28% de las
aplicaciones analizadas.
https://www.veracode.com/security/sql-injection
• El siguiente sitio web recopila ejemplos de compañías que se han

visto afectadas por vulnerabilidades de inyección de SQL.
https://codecurmudgeon.com/wp/sql-injection-hall-of-shame/
27
Inyección en ficheros de log (1)
• Los registros de log permiten construir un histórico de todos los
eventos, acciones, errores, etc. que se producen durante la ejecución
de un programa.
• Idealmente, los ficheros de log se pueden utilizar para reconstruir el
escenario en el que se ha producido algún problema.
• La vulnerabilidad de inyección en este tipo de ficheros (en inglés es
conocida como Log Injection o Log Forgery) se produce cuando en los
registros de log se escriben mensajes generados a partir de entradas
de usuario y esos datos no han sido correctamente validados y/o
escapados.
28
• Las principales consecuencias de este ataque son:
- Falsificación de los registros de log con el objetivo de enmascarar
algún otro ataque y dificultar su localización a los responsables de
analizar los ficheros.
- Inyección de código ejecutable, por ejemplo JavaScript, para
explotar capacidades específicas del software que se utiliza para
visualizar los logs. Esta variante la estudiaremos con más detalle
en el capítulo dedicado a inyección de JavaScript (XSS).
29
• El siguiente ejemplo muestra un fragmento de código que genera un
registro de log cuando los datos introducidos por el usuario son
inválidos.
• En este caso, el parámetro de entrada “val” se espera que sea
numérico.
Fuente: owasp.org
30
• Cuanto la entrada del usuario no es numérica, en el log se mostrará un registro
similar al siguiente:
twenty-one
• Pero cuando, además, la entrada contiene caracteres especiales (como por

ejemplo, saltos de línea codificados) el atacante consigue introducir registros de
log adicionales.
twenty-one%0a%0aINFO:+User+logged+out%3dbadguy
31
Inyección en ficheros de log (5): prevención
• Para prevenir los ataques de inyección en ficheros de log, es
necesario procesar y escapar todas las entradas que proceden del
usuario.
• Siempre que sea posible, es recomendable utilizar las capacidades
específicas de la librería que genera los ficheros de log.
32
• Ejemplo en la plataforma Java: log4j. Esta librería permite gestionar
todos los mensajes de log que se envían desde la aplicación.
• En su fichero de configuración (log4j.xml o log4j.properties), es
posible establecer diferentes parámetros:
https://logging.apache.org/log4j/2.x/manual/layouts.html
33
• Entre todos los parámetros configurables, destacan los siguientes:
- Localización del fichero.
- Tamaño máximo de ese fichero.
- El formato de cada registro de log, con los diferentes campos que se pueden
incluir: fecha y hora, mensaje, proceso, clase Java, etc.
• A la hora de especificar el formato del mensaje, es posible escapar
algunos caracteres conflictivos usando la función predefinida enc. De
este modo, es posible prevenir el ataque sin necesidad de modificar el
código fuente, tan solo cambiando la configuración.
34
Inyección en ficheros de log (8): referencias
• Esta vulnerabilidad tiene su propia entrada en el listado del CWE:
- CWE-117: Improper Output Neutralization for Logs.
• Los patrones de ataque relacionados con esta vulnerabilidad

registrados en el CAPEC son:
- CAPEC-93: Log Injection-Tampering-Forging (el objetivo de este ataque son
los ficheros de log de la aplicación).
- CAPEC-81: Web Logs Tampering (el objetivo de este ataque son los ficheros
de log del servidor web).
35
Inyección en las cabeceras HTTP (1)
• Se produce inyección en las cabeceras HTTP (conocido en inglés como
HTTP Header Injection) cuando se utilizan entradas de usuario
incorrectamente escapadas, para añadir cabeceras HTTP de forma
dinámica e inesperada.
• El ataque más conocido de inyección en las cabeceras HTTP es la
inyección de saltos de línea con el objetivo de “partir” la cabecera
para insertar contenido adicional (HTTP Response Splitting).
• Este ataque se puede combinar con inyección de JavaScript (se
estudiará más adelante).
36
• En el siguiente ejemplo se añade una cookie de forma dinámica con el
contenido del parámetro “author”, que es un parámetro de entrada
proporcionado por el usuario.
• Al añadir la cookie se genera de forma dinámica la cabecera Set-

Cookie que tendrá como valor el nombre proporcionado por el
usuario.
37
• Pero si los datos de entrada no se validan, el atacante puede establecer un valor
como el siguiente:
“author=Wiley Hacker\r\nContent-Length:999\r\n\r\n<html>malici...”
• De tal forma que podría introducir saltos de línea que “rompen” la petición e
insertan el contenido malicioso.
38
Inyección en las cabeceras HTTP (4): prevención
• Para prevenir los ataques de inyección en las cabeceras HTTP es
necesario realizar alguna de las siguientes acciones.
- Validar las entradas de usuario de tal forma que sólo se permita un
subconjunto de caracteres seguros a la hora de construir la cabecera. Esta es
una técnica de lista blanca.
- Codificar las entradas de usuario para escapar aquellos caracteres que
puedan resultar problemáticos, poniendo especial atención en los saltos de
línea.
39
Inyección en las cabeceras HTTP (5): referencias
• Las entradas en el CWE relacionadas con esta vulnerabilidad son las
siguientes:
- CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers
('HTTP Response Splitting').
- CWE-644: Improper Neutralization of HTTP Headers for Scripting Syntax.
• Los patrones de ataque del CAPEC relacionados con esta

vulnerabilidad son:
- CAPEC-34: HTTP Response Splitting.
- CAPEC-86: XSS Through HTTP Headers.
40
Inyección en SMTP (1)
• SMTP (Simple Mail Transfer Protocol) es un protocolo que permite el
envío de correos electrónicos.
Fuente: wikipedia.org
41
• Se produce inyección en el un mensaje SMTP cuando a través de
entradas de usuario, un atacante consigue insertar cabeceras
adicionales u otros elementos dentro de un correo electrónico.
• En el siguiente ejemplo se muestra una petición POST que se genera
desde un formulario de contacto que tiene los parámetros from,
replyTo y message.
42
• A través de los siguientes datos de entrada, que en el ejemplo de la figura
incluyen un salto de línea, es posible añadir nuevas cabeceras.
• En este caso se añade la cabecera BCC que enviará una copia del mensaje a un
destinatario diferente.
• Este tipo de técnicas se suelen utilizar para ataques de phising (capturar un
mensaje) o para enviar mensajes de spam (enviar un mensaje a múltiples
destinatarios).
43
Inyección en SMTP (4): prevención
• De forma similar a como sucede en otro tipo de vulnerabilidades de
inyección de código, para prevenir los ataques de inyección en
mensajes SMTP hay dos posibles soluciones:
- Listas blancas de valores válidos. Por ejemplo, cuando la lista de
posibles destinatarios es un conjunto conocido de direcciones de
correo.
- Escapado de los caracteres reservados en el protocolo SMTP. Por
ejemplo, cuando los fragmentos del mensaje SMTP se crean a
partir de los valores de los campos de un formulario.
44
Inyección en SMTP (5): referencias
• En este caso, no hay una entrada específica en la lista del CWE
asociada a esta vulnerabilidad y se puede incluir dentro de la
categoría genérica:
- CWE-150: Improper Neutralization of Escape, Meta, or Control Sequences.
• Los patrones de ataque almacenados en el CAPEC relacionados con

inyección dentro del protocolo SMTP son:
- CAPEC-134: Email Injection.

- CAPEC-41: Using Meta-characters in E-mail Headers to Inject Malicious
Payloads.
45
Inyección de comandos del sistema operativo (1)
• La inyección de comandos del sistema operativo es una vulnerabilidad
que permite la ejecución arbitraria de comandos en el sistema en el
que se ejecuta la aplicación.
• En el siguiente ejemplo, la aplicación ejecuta un ping a una dirección
IP a través de una llamada al sistema operativo.
• Si la dirección IP la proporciona el usuario a través de un formulario y
esta dirección no se valida de forma adecuada, es posible insertar
comandos adicionales. En este ejemplo, se produce el borrado de un
directorio a través de la inserción del comando rm.
46
Inyección de comandos del S.O. (2): prevención
• En general, salvo que sea imprescindible, es recomendable evitar este
tipo de llamadas al sistema operativo.
• Y cuando no quede más remedio que utilizar scripts externos o
comandos del sistema operativo parametrizados, es imprescindible
validar los datos de entrada, bien con listas blancas de valores válidos
o bien a través de escapados.
47
Inyección de comandos del S.O. (3): referencias
• Las entradas en el CWE relacionadas con esta vulnerabilidad son:
- CWE-78: Improper Neutralization of Special Elements used in an OS
Command ('OS Command Injection').

vulnerabilidad son:
- CAPEC-88: OS Command Injection.
- CAPEC-248: Command Injection (genérica).
- CAPEC-15: Command Delimiters (genérica).
48
Inyección en LDAP (1)
• LDAP (Lightweight Directory Access Protocol) o en castellano
Protocolo Ligero de Acceso a Directorios) es un protocolo que permite
el acceso a un servicio de directorio para buscar diversa información
en un entorno de red (RFC 4511).
• Un directorio está formado por un conjunto de objetos con atributos
organizados de una manera jerárquica.
• Para acceder a este directorio se utilizan una serie de filtros que
tienen una sintaxis concreta (RFC 4515).
49
• La sintaxis de estos filtros permite expresiones complejas a través de
operadores lógicos AND, OR, NOT.
String q = “(&(USER = ” + user + “)(PASSWORD = “ + password + “))”;
• La consulta anterior permite la autenticación de un usuario en el

directorio LDAP.
• De forma similar a lo que sucedía en inyección de SQL, si los
caracteres especiales en este lenguaje no se procesan, es posible
modificar la semántica de la consulta y ejecutar un ataque.
50
• En LDAP también es posible ejecutar consultas a ciegas (Blind LDAP
Injection) a través de filtros booleanos.
• El siguiente ejemplo permite obtener el salario de un trabajador
utilizando está técnica.
const q = “(&(objectClass= ” + object + “)...)”;
(&(objectClass=*)(uid=bob)(salary>=1))…) -> TRUE

(&(objectClass=*)(uid=bob)(salary>=2))…) -> TRUE
(&(objectClass=*)(uid=bob)(salary>=3))…) -> FALSE
51
Inyección en LDAP (4): prevención
• Para prevenir los ataques de inyección en los filtros de autenticación
LDAP, la defensa más habitual es el escapado de las variables de
entrada.
• Y siempre que sea posible, es recomendable utilizar una lista blanca
de valores válidos para los parámetros de entrada. Aunque en el caso
de autenticación de usuarios, esta no será la opción más habitual.
• Adicionalmente, se recomienda que el usuario que consulta el LDAP
tenga los permisos imprescindibles, para minimizar los riesgos en
caso de que se produzca algún ataque.
52
Inyección en LDAP (5): referencias
• Las entradas en el CWE relacionadas con esta vulnerabilidad son:
- CWE-90: Improper Neutralization of Special Elements used in an LDAP
Query ('LDAP Injection')
- CWE-943: Improper Neutralization of Special Elements in Data Query Logic
(genérica).

vulnerabilidad son:
- CAPEC-136: LDAP Injection.
53
Inyección en XML y XPath (1)
• Se produce inyección en XML cuando los datos de entrada contienen caracteres
reservados en ese lenguaje, de tal manera que el documento que se genera no es
el esperado.
• El siguiente ejemplo muestra una transacción que se realiza a través del
intercambio de mensajes XML. Para componer el documento, se utiliza una
plantilla que se rellena con los datos procedentes de un formulario web (importe
total, tarjeta de crédito y dirección de envío).
54
• Si en los datos de entrada se añaden caracteres reservados en XML, el
resultado puede ser una modificación inesperada en el documento.
• En este ejemplo, se podría llegar a modificar el importe total de la
transacción.
hacking street s/n </address><total>50</total><address>
55
• XPath es un lenguaje de consulta de documentos XML sobre el que
también es posible realizar inyección de código si las entradas de
usuario no se procesan de forma adecuada.
• Para ilustrar esta vulnerabilidad, el siguiente ejemplo muestra una
base de datos de usuarios almacenada en formato XML.
56
• Sobre la base de datos de la figura anterior, la siguiente consulta
XPath permite realizar el proceso de autenticación.
• Esta consulta se construye de forma dinámica concatenando el
usuario y la contraseña proporcionados por el usuario, típicamente a
través de un formulario web.
57
• En un escenario normal, la consulta XPath sería similar a la siguiente:
• Pero si en los datos de entrada se utilizan caracteres especiales como

por ejemplo, las comillas simples:
Bob' or '1'='1
• El resultado sería una expresión XPath que permite autenticar a
cualquier usuario sin necesidad de conocer su contraseña.
58
Inyección en XML y XPath (6): prevención
• Para prevenir los ataques de inyección en XML se debe realizar una
validación adecuada de los datos proporcionados por el usuario,
escapando aquellos caracteres que puedan dar lugar a conflictos:
" → "
‘ → '
< → <
> → >
& → &
59
• Las reglas de escapado varían en función de dónde se va a añadir el contenido:
- En el texto dentro de una etiqueta: lo más seguro es escapar los 5 caracteres especiales
aunque la comilla doble, la comilla simple y el carácter de mayor (>) no es necesario
escaparlos.
- En los valores de atributos: lo más seguro es escapar los 5 caracteres especiales aunque el
carácter de mayor (>) no es necesario escaparlo y tampoco la comilla doble cuando el valor
del atributo está contenido dentro de comillas simples (y al revés).
- En los comentarios: no se debe realizar el escapado de ninguno de los 5 caracteres
especiales.
- Dentro de un CDATA: no se debe realizar el escapado de ninguno de los 5 caracteres. La
secuencia de finalización ]]> no está permitida por lo que tampoco es necesario escaparla.
- Instrucciones de procesamiento: tampoco se debe realizar el escapado de ninguno de los 5
caracteres especiales.
60
• En muchos casos, el tipo de dato nos permitirá realizar esta validación
de forma sencilla (por ejemplo, cuando los datos son numéricos,
booleanos o enumerados).
• Además de escapar los caracteres reservados, un mecanismo más
general de validación es a través de XML Schemas o DTD pero es
necesario tener cuidado con otra vulnerabilidad muy peligrosa que se
estudiará más adelante: XEE (inyección de entidades externas).
61
• El siguiente ejemplo muestra el esquema XSD que se podría utilizar para validar el
documento XML del ejemplo anterior. Para los diferentes campos se establece el
tipo de dato (decimal, string, etc.), el número máximo y mínimo de ocurrencias,
y también el formato de la tarjeta de crédito.
62
• Para prevenir los ataques de inyección en XPath, es necesario
procesar de forma adecuada los caracteres especiales de este
lenguaje: ()='[]:,*/ y el espacio en blanco.
• Algunas APIs permiten establecer variables de forma similar a las
sentencias parametrizadas de SQL, por ejemplo, en el lenguaje Java se
podrían utilizar las siguientes clases:
- javax.xml.namespace.QName;
- javax.xml.xpath.XPathVariableResolver;
63
Inyección en XML y XPath (11): referencias.
• Las entradas en el CWE relacionadas con estas vulnerabilidades son:
- CWE-91: XML Injection (aka Blind XPath Injection).
- CWE-643: Improper Neutralization of Data within XPath Expressions ('XPath
Injection').
• Los patrones de ataque del CAPEC relacionados con estas

vulnerabilidades son:
- CAPEC-250: XML Injection.
- CAPEC-83: XPath Injection.
64
Inyección de código: conclusiones
• Los lenguajes que generan expresiones o consultas de forma dinámica se pueden ver
afectados por ataques de inyección de código. Por lo tanto, durante la generación de estas
expresiones, es imprescindible validar todos los datos de entrada de la aplicación.
• Siempre que exista la posibilidad de formatear los datos de entrada utilizando un método
estándar, por ejemplo, las sentencias parametrizadas en SQL, esa es la técnica que se
debería utilizar.
• Cuando no existe una forma estándar de formatear los datos, la técnica de prevención a
través de listas blancas es las más efectiva dado que el conjunto de valores de entrada queda
perfectamente acotado.
• Pero esta técnica no siempre es posible, con lo que en muchas ocasiones es necesario
procesar manualmente los datos y neutralizar los caracteres especiales de cada lenguaje
(escapado).
• Para algunos lenguajes existen librerías de contrastada eficacia, que ya realizan ese
procesamiento (escapado). En estos casos, siempre es preferible utilizar esas librerías a la
alternativa de realizar una implementación propia.
65

Apartado 2.2.2 Inyección de Código

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Apartado 2.2.2 Inyección de Código

Cargado por

Copyright:

Formatos disponibles

2.2.

• El siguiente ejemplo, se podría utilizar para obtener la contraseña del usuario a

• Y también es posible insertar nuevas tuplas. En el siguiente ejemplo, se ejecuta la

“cat=2 and 1=2”

“cat=2 and (SELECT 1 from users)=1”

• La consulta que se ejecuta contra la base de datos contiene los

• De tal forma que la consulta que se genera no se ve afectada por

• Más información en el siguiente enlace:

CWE-89: Improper Neutralization of Special Elements used in an SQL

• Dentro de la plataforma Java, también hay otra variante de inyección

CWE-564: SQL Injection: Hibernate.

- CAPEC-66: SQL Injection

• Y sólo desde enero a abril de 2023 se registraron un total de 792

• El siguiente sitio web recopila ejemplos de compañías que se han

• Pero cuando, además, la entrada contiene caracteres especiales (como por

• Los patrones de ataque relacionados con esta vulnerabilidad

• Al añadir la cookie se genera de forma dinámica la cabecera Set-

• Los patrones de ataque del CAPEC relacionados con esta

• Los patrones de ataque almacenados en el CAPEC relacionados con

- CAPEC-134: Email Injection.

• Los patrones de ataque del CAPEC relacionados con esta

• La consulta anterior permite la autenticación de un usuario en el

const q = “(&(objectClass= ” + object + “)...)”;

(&(objectClass=*)(uid=bob)(salary>=1))…) -> TRUE

• Los patrones de ataque del CAPEC relacionados con esta

• Pero si en los datos de entrada se utilizan caracteres especiales como

• Los patrones de ataque del CAPEC relacionados con estas

También podría gustarte