Los 10 principales

riesgos en
aplicaciones web
(OWASP Top 10 2017)
 Open Web Application Security Project

• Una comunidad libre y abierta enfocada en la

seguridad de las aplicaciones
• OWASP Top Ten 2017
– Lista de los 10 más importantes y comunes riesgos en
aplicaciones web
– Busca crear conciencia en el origen de los problemas de
seguridad en las aplicaciones web
– La seguridad de las aplicaciones es responsabilidad de
los desarrolladores
Sobre riesgos y no solo vulnerabilidades
 OWASP Top Ten 2017 Edition

A2: Fallos de A3: Exposición de A4: XML Entidades

A1: Inyección
Autenticación datos sensibles Externas (XXE)

A6: Mala
A5: Fallos de A7: Cross-Site A8: Insecure
configuración de
Control de Acceso Scripting (XSS) Deserialization
la seguridad

A9: Usar
A10: Insufficient
componentes con
Logging &
vulnerabilidades
Monitoring
conocidas
 A1: Inyección

• Engañar a la aplicación al incluir instrucciones

que no esperaba en los datos enviados a un
interprete
• Interprete: Toma una cadena y la interpreta
como instrucciones (SQL, LDAP, Shell, Xpath …)
• Muy común con un impacto severo (datos
modificados, acceso a cuentas o incluso al SO)
 A1: Ejemplo Inyección SQL

El atacante usa una forma

para enviar como datos:

Communication
Administration
aplicación

Bus. Functions
aplicación

E-Commerce
Transactions
de

Knowledge
Respuesta
Capa de

Accounts DB Table ‘ OR 1=1 --

Finance
SQL

Mgmt
Petición HTTP Base de
Capa

HTTP query 
 Datos
 
  La Aplicación reenvía el
Custom Code ataque a la base de datos:
Plataforma SELECT * FROM
accounts WHERE
acct=’’ OR 1=1—’
Red
de Red

La Base de datos entrega

Firewall

Firewall
Firewall

Firewall
Capa de

la información a la
aplicación
Capa

El Atacante obtiene los

datos
 A1: ¿Cuál fue el problema?

String query = "SELECT * FROM

accounts WHERE custID='" +
request.getParameter("id") + "'";
Statement st = conn.createStatement();
ResultSet rs = st.executeQuery(query);
 A1: ¿Cuál fue el problema?

String query = "SELECT * FROM

accounts WHERE custID='" +
request.getParameter("id") + "'";
PrepareStatement ps = conn.
prepareStatement(query);
ResultSet rs = ps.executeQuery();
 A1: ¿Cuál fue el problema?

String query = "SELECT * FROM

accounts WHERE custID=?";
PrepareStatement ps = conn.
prepareStatement(query);
ps.setString(1,
request.getParameter("id") );
ResultSet rs = ps.executeQuery();
 A1: Recomendaciones

• Evitar usar interpretes

• Usar interfaces que soporten variables ligadas
• Codificar toda entrada antes de pasarla a un
interprete
• Validar todos los valores del usuario contra una
lista de palabras aceptadas (white list)
• Minimizar los privilegios a la base de datos
 A1: Caso de Abuso

• historia de usuario:

Como atacante, realizaré un ataque de

inyección (consultas SQL, LDAP, XPath o NoSQL,
comandos del sistema operativo, analizadores
XML, encabezados SMTP, lenguajes de
expresión y consultas ORM) contra los campos
de entrada de las interfaces de usuario o API.
 A1: Más información

• Para mas detalles, se recomienda leer:

https://www.owasp.org/index.php/
SQL_Injection_Prevention_Cheat_Sheet
 A2: Fallos de Autenticación

• HTTP es un protocolo “stateless”

– Las credenciales deben viajar con cada petición
– Debería usar TSL para todo lo que requiera
autenticación
• Se usa el SESSION ID para mantener el estado de
la sesión
• Como Impacto se puede comprometer las
cuentas de los usuarios o secuestrar las sesiones
 A2: Fallos típicos

• El SESSION ID puede estar expuesto en la red,

en los navegadores, logs, URLs, …
• El uso de puertas alternas (cambia mi
contraseña, recordar mi contraseña, recuperar
mi contraseña, pregunta secreta, salir, etc.)
 A2: Recomendaciones

• Verificar la Arquitectura de la aplicación

– La autenticación debería ser simple, centralizada y
estandarizada
– Utiliza el mecanismo de control de SESSION ID que
provee el contenedor
– Usar TSL para proteger las credenciales y la sesión
siempre
 A2: Recomendaciones

• Verificar la Implementación de la aplicación

– Revisar el certificado TSL
– Examinar todas las funciones relacionadas a la
autenticación
– Verificar que el “Salir” en verdad destruya la sesión
 A2: Casos de Abuso

Como atacante, tengo acceso a cientos de millones de combinaciones

válidas de nombre de usuario y contraseña para el relleno de credenciales.

Como atacante, tengo listas de cuentas administrativas predeterminadas,

fuerza bruta automatizada y herramientas de ataque de diccionario que
utilizo contra áreas de inicio de sesión de la aplicación y sistemas de
soporte.

Como atacante, manipulo tokens de sesión usando tokens caducados y

falsos para obtener acceso.
 A2: Más Información

• Para mas detalles, se recomienda leer:

https://www.owasp.org/index.php/
Authentication_Cheat_Sheet
 A3: Exposición de datos sensibles

• Almacenando y transfiriendo datos sensibles de

manera insegura
– Falla de identificar datos sensibles
– Falla de identificar los lugares donde estos datos se
guardan
– Falla de identificar los lugares en donde estos datos son
enviados
– Falla de proteger estos datos apropiadamente en todo
lugar
 A3: Impacto

• Acceso o modificación por parte delos atacantes a

información privada o confidencial
• Los atacantes obtienen secretos que pueden utilizar en
otros ataques
• Afecta la reputación del sitio / aplicación
• Costo de recuperación del incidente
– Análisis forense, envío de disculpas, reexpedición de tarjetas,
seguros contra robo de identidad
• Demandas
 A3: Ejemplo

1 La victima da su tarjeta de
crédito para realizar una
reservación

Communication
Administration

Bus. Functions
E-Commerce
Transactions

Knowledge
Accounts
Finance

Mgmt
4 Un empleado
Custom Code
malicioso roba los
números de tarjetas
de crédito Log files

3 Los logs están disponibles a
los miembros del equipo de
desarrollo para debugueo
2 Por un error en la
comunicación con el
gateway de pagos, el
sistema logguea el error
junto con la tarjeta
 A3: Recomendaciones
• Identificar claramente los datos sensibles y los
lugares en donde se almacenan o transportan
• Usa mecanismos adecuados de protección
(cifrado de archivos, bases de datos, datos)
• Usa mecanismos estándar cuidando el proceso
de generación, distribución y almacenamiento
de llaves
• El sistema debe estar preparado para cambiar
las llaves
 A3: Verificar la implementación

• ¿Se usan algoritmos fuertes y estándar?

• ¿Las llaves, certificados y contraseñas están
guardados y protegidos adecuadamente?
• ¿Existe un mecanismo seguro para distribuir y
un plan para el cambio de llaves?
 A3: Capa de transporte

• Usar siempre TLS en todas las comunicaciones

con datos sensibles
• Cifrar los mensajes de manera individual antes
de la transmisión
• Firmar los mensajes antes de la transmisión
• Verificar los certificados TSL antes de usarlos
 A3: Caso de abuso
Como atacante, robo claves que estaban expuestas en la aplicación para obtener
acceso no autorizado a la aplicación o al sistema.

Como atacante, ejecuto ataques man-in-the-middle para obtener acceso al tráfico y

aprovecharlo para obtener datos confidenciales y posiblemente obtener acceso no
autorizado a la aplicación.

Como atacante, robo datos de texto sin cifrar del servidor, mientras está en tránsito, o
del cliente del usuario, p. Ej. navegador para obtener acceso no autorizado a la
aplicación o sistema.

Como atacante, encuentro y apunto algoritmos criptográficos viejos o débiles

capturando tráfico y rompiendo el cifrado.
 A3: Más Información

• Para mas detalles se recomienda leer:

https://www.owasp.org/index.php/
Transport_Layer_Protection_Cheat_Sheet
 A4: XML External Entities (XXE)

• Errores comunes
Muchos procesadores XML más antiguos o mal configurados
evalúan las referencias de entidades externas dentro de los
documentos XML.

• Impacto:
Las entidades externas se pueden utilizar para divulgar archivos
internos mediante el controlador de archivos URI, recursos
compartidos de archivos internos, escaneo de puertos internos,
ejecución remota de código y ataques de denegación de servicio.
 A4: Ejemplo

• Los atacantes pueden explotar procesadores

XML vulnerables si pueden cargar XML o incluir
contenido hostil en un documento XML,
explotando código vulnerable, dependencias o
integraciones
 A4: Caso de Abuso

Como atacante, exploto áreas vulnerables de la aplicación donde el usuario o el sistema

puede cargar XML para extraer datos, ejecutar una solicitud remota desde el servidor,
escanear sistemas internos, realizar un ataque de denegación de servicio, así como
ejecutar otros ataques. .

Como atacante, incluyo contenido hostil en un documento XML que se carga en la

aplicación o sistema para extraer datos, ejecutar una solicitud remota desde el servidor,
escanear sistemas internos, realizar un ataque de denegación de servicio, así como
ejecutar otros Ataques

Como atacante, incluyo código XML malicioso para explotar código vulnerable,
dependencias o integraciones para extraer datos, ejecutar una solicitud remota desde el
servidor, escanear sistemas internos, realizar un ataque de denegación de servicio (por
ejemplo, el ataque Billion Laughs), también como ejecutar otros ataques.
 A4: XML External Entities (XXE)
• Para mas detalles se recomienda leer:

https://cheatsheetseries.owasp.org/cheatsheets
/XML_External_Entity_Prevention_Cheat_Sheet.
html
 A5: Fallo de controles de acceso
• Las restricciones sobre lo que los usuarios autenticados
pueden ser que a menudo no se aplican correctamente.

• Consecuencias
– Los atacantes pueden aprovechar estas fallas para acceder a
funciones y / o datos no autorizados, como acceder a las cuentas de
otros usuarios, ver archivos confidenciales, modificar los datos de
otros usuarios, cambiar los derechos de acceso, etc.
• Impacto
– Poder invocar funciones y servicios para los que no se está
autorizado
– Acceder a la información de otros usuarios
– Realizar acciones privilegiadas
 A5: Ejemplo
https://www.bancoenlinea.com/usuario/obtenerCuentas
• El atacante observa que el el URL esta su rol
“usuario”
• Lo modifica probando otros roles
/admin/obtenerCuentas
/manager/obtenerCuentas
• Obtiene acceso a información privilegiada
 A5: Recomendaciones

• Para cada función un sitio debe:

– Restringir el acceso para sólo usuarios
autenticados (si no es público)
– Asegurarse de cumplir los permisos basados en
usuarios o roles (Si es privado)
– Bloquear por completo las peticiones a paginas no
autorizadas (archivos de configuración, archivos de
logs, código fuente, etc)
 A5: Verificaciones

• Verificar que cada URL (y cada uno de sus

parámetros) que hacen referencia a una función
estén protegidos por:
– Un filtro externo (como el web.xml de Java EE)
– Validaciones internas en TU código
• Verificar que el servidor no entregue tipos de
archivo no autorizados
• Usar Zed Attack Proxy (ZAP) de OWASP o un
navegador para falsificar solicitudes no autorizadas
 A5: Caso de abuso
Como atacante, evito las comprobaciones de control de acceso
modificando la URL, el estado interno de la aplicación o la página HTML,
o simplemente usando una herramienta de ataque API personalizada.

Como atacante, manipulo la clave principal y la cambio para acceder al

registro de usuarios de otra persona, lo que permite ver o editar la
cuenta de otra persona.

Como atacante, manipulo sesiones, tokens de acceso u otros controles

de acceso en la aplicación para actuar como usuario sin iniciar sesión, o
actuar como administrador / usuario privilegiado cuando inicie sesión
como usuario.
 A5: Caso de abuso
Como atacante, aprovecho la manipulación de metadatos, como
reproducir o alterar un token de control de acceso JSON Web Token
(JWT) o una cookie o campo oculto manipulado para elevar privilegios o
abusar de la invalidación de JWT.

Como atacante, aprovecho la mala configuración de CORS de

intercambio de recursos de origen cruzado que permite el acceso no
autorizado a la API.

Como atacante, obligo a navegar en páginas autenticadas como usuario

no autenticado o en páginas privilegiadas como usuario estándar.
 A5: Caso de abuso

Como atacante, accedo a API sin controles de acceso para

POST, PUT y DELETE.

Como atacante, me dirijo a las claves criptográficas

predeterminadas en uso, claves criptográficas débiles
generadas o reutilizadas, o claves en las que falta la rotación.

Como atacante, encuentro áreas donde el agente de usuario

(por ejemplo, aplicación, cliente de correo) no verifica si el
certificado de servidor recibido es válido y realiza ataques
donde obtengo acceso no autorizado a los datos.
 A5: Más información

• Para detalles sobre Zed Attack Proxy (ZAP)

https://code.google.com/p/zaproxy/wiki/
Introduction
 A6: Mala configuración de la seguridad

• Las aplicaciones web dependen de una plataforma

segura
– Todo desde el SO al servidor de aplicaciones
• ¿Es tu código fuente un secreto?
– La seguridad no debe requerir la secrecía del código
• La administración de la configuración debe abarcar
todas las partes de la aplicación
– Las contraseñas deben cambiarse en producción
• Impacto: acceso por cuentas por defecto o mala
configuración de los servicios
 A6: Caso de Abuso

Como atacante, encuentro y aprovecho las configuraciones de refuerzo de seguridad que

faltan en cualquier parte de la pila de aplicaciones, o los permisos configurados
incorrectamente en los servicios en la nube.

Como atacante, encuentro funciones innecesarias que están habilitadas o instaladas (por
ejemplo, puertos, servicios, páginas, cuentas o privilegios innecesarios) y ataco o aprovecho
la debilidad.

Como atacante, utilizo cuentas predeterminadas y sus contraseñas para acceder a sistemas,
interfaces o realizar acciones en componentes que no debería poder hacer.

Como atacante, encuentro áreas de la aplicación donde el manejo de errores revela rastros
de pila u otros mensajes de error demasiado informativos que puedo usar para una mayor
explotación.
 A6: Caso de Abuso

Como atacante, encuentro áreas donde los sistemas actualizados, las

últimas funciones de seguridad están deshabilitadas o no configuradas de
forma segura.

Como atacante, encuentro configuraciones de seguridad en los servidores

de aplicaciones, marcos de aplicaciones (por ejemplo, Struts, Spring,
ASP.NET), bibliotecas, bases de datos, etc. que no están configuradas en
valores seguros.

Como atacante, encuentro que el servidor no envía encabezados o

directivas de seguridad o que no están configurados para valores seguros.
 A6: Recomendaciones
• Verifique la administración de la configuración
– Guía de “hardening” de la aplicación
• La automatización es de mucha ayuda aquí
– Debe abarcar toda la plataforma y la aplicación
– Analizar los efectos en la seguridad que generan los
cambios
• ¿Puedes tener un “dump” de la configuración de
la aplicación?
– Si no puedes verificarlo no es seguro
– Los scanners encuentran problemas genéricos de
configuración y falta de parches
 A7: Cross-Site Scripting (XSS)

• Código de un atacante es enviado a un usuario

– Guardado en bases de datos
– Reflejado vía una forma web (campos de forma, ocultos, URLs,
etc)
– Enviado directamente al motor de JavaScript
• Impacto
– Robo de información (Sesión, datos, redirigir al usuario a
páginas de phishing o malware)
– Instalar un XSS proxy que permite al atacante observar el
comportamiento de los usuarios de un sitio web vulnerable
 A7: Ejemplo
1 El Atacante pone una trampa
- Ejemplo en el perfil
Sitio Web Vulnerable
El atacante pone un script
malicioso que se guarda
en la base de datos de la

Knowledge Mgmt
aplicación

Communication
Administration

Bus. Functions
E-Commerce
Transactions
2 La victima en la página entra

Accounts
Finance
Al perfil del atacante
Custom Code

El script corre en el
navegador de la victima
con acceso completo al
DOM y a las cookies

3 Silenciosamente el script manda la sesión de la victima al atacante

 A7: Recomendaciones

• Elimine el XSS
– No incluir datos suministrados por el usuario en las
páginas generadas
• Defensa contra el XSS
– Codifique todos los datos suministrados por el usuario
(OWASP ESAPI, Java Encoders)
– Validación de datos vía “white list”
– Para grandes volúmenes de HTML sanitizar los datos con
OWASP AntiSamy para hacerlos seguros
 A7: Contextos de ejecución del HTML
#1: ( &, <, >, " )  &entity; ( ', / )  &#xHH;
ESAPI: encodeForHTML()

HTML Element Content

(e.g., <div> Algún texto a desplegar </div> ) #2: Todos no-alfanumericos < 256  &#xHH;
ESAPI: encodeForHTMLAttribute()

HTML Attribute Values

(e.g., <input name='persona' type='TEXT'
value=’Valor'> ) #3: Todos no-alfanumericos < 256  \xHH
ESAPI: encodeForJavaScript()
JavaScript Data
(e.g., <script>
someFunction(‘DATO’)</script> )
#4: Todos no-alfanumericos < 256  \HH
ESAPI: encodeForCSS()
CSS Property Values
(e.g., .pdiv a:hover {color: red; text-decoration:
underline} )
#5: Todos no-alfanumericos < 256  %HH
URI Attribute Values ESAPI: encodeForURL()
(e.g., <a href=" http://site.com?search=DATO" )

Cualquier otro contexto NO DEBE incluir datos no confiables

 A7: Caso de Abuso
• Como atacante, realizo XSS reflejado donde la aplicación o API
incluye entrada de usuario no validada y sin escape como parte
de la salida HTML. Mi ataque exitoso puede permitir que el
atacante ejecute HTML y JavaScript arbitrarios en el navegador
de mi víctima. Por lo general, la víctima deberá interactuar con
algún enlace malicioso que apunte a una página controlada por
el atacante, como sitios web maliciosos, anuncios o similares.
 A7: Caso de Abuso
• Como atacante, realizo XSS almacenado donde la
aplicación o API almacena la entrada de usuario no
desinfectada que es vista en un momento posterior por
otro usuario o un administrador.

Como atacante, realizo DOM XSS donde los marcos de

JavaScript, las aplicaciones de una sola página y las API
que incluyen dinámicamente datos controlables por el
atacante en una página son vulnerables a DOM XSS.
 A7: Más información

• Para mas detalles, se recomienda leer:

https://www.owasp.org/index.php/XSS_(Cross
_Site_Scripting)
_Prevention_Cheat_Sheet
 A8:Insecure Deserialization

• A menudo conduce a la ejecución remota de código.

Incluso si las fallas de deserialización no dan como
resultado la ejecución remota de código, se pueden usar
para realizar ataques, incluidos ataques de reproducción,
ataques de inyección y ataques de escalada de privilegios.

La explotación de la deserialización es algo difícil, ya que los

exploits listos para usar rara vez funcionan sin cambios o
ajustes en el código del exploit subyacente
 A8: Caso de Abuso

Como atacante, encuentro áreas de la aplicación y API donde se

puede proporcionar la deserialización de objetos hostiles o
manipulados. Como resultado, puedo enfocarme en ataques
relacionados con un objeto y estructura de datos donde el atacante
modifica la lógica de la aplicación o logra la ejecución de código
remoto arbitrario si hay clases disponibles para la aplicación que
pueden cambiar el comportamiento durante o después de la
deserialización. O me centro en los ataques de manipulación de
datos, como los ataques relacionados con el control de acceso, en
los que se utilizan estructuras de datos existentes pero se cambia el
contenido.
 A8: Más información

• para más detalles se recomienda leer:

https://cheatsheetseries.owasp.org/cheatshee
ts/Deserialization_Cheat_Sheet.html
 A9: Usar componentes con vulnerabilidades
conocidas

https://www.aspectsecurity.com/news/the-unfortunate-reality-of-insecure-libraries/
A9: Ejemplo
 A9: Recomendaciones

• Ideal
– Periódicamente y de manera automática realizar
verificaciones de componentes usados
• Mínimo
– A mano revisar periódicamente si los componentes
están actualizados
– Revisar cuales componentes cuentan con
vulnerabilidades reportadas
• CVE y otros repositorios de vulnerabilidades
 A9: Caso de Abuso
• Como atacante, encuentro paquetes comunes
de código abierto o de código cerrado con
debilidades y realizo ataques contra
vulnerabilidades y exploits que se revelan.
 A9: Más información

• En el mundo Java:

https://www.owasp.org/index.php/
OWASP_Dependency_Check

• En .Net
https://github.com/OWASP/SafeNuGet
 A10: Insuficient Logging & Monitoring

Un registro y una supervisión insuficientes, junto con

una integración faltante o ineficaz con la respuesta a
incidentes, permiten a los atacantes atacar aún más los
sistemas, mantener la persistencia, cambiar a más
sistemas y manipular, extraer o destruir datos. La
mayoría de los estudios de infracciones muestran que
el tiempo para detectar una infracción es de más de
200 días, generalmente detectados por partes externas
en lugar de procesos internos o monitoreo.
 A10: Impacto

• La explotación de la tala y el monitoreo insuficientes

es la base de casi todos los incidentes importantes.
Los atacantes dependen de la falta de supervisión y
respuesta oportuna para lograr sus objetivos sin ser
detectados. En 2016, la identificación de una
infracción tomó un promedio de 191 días, por lo que
hubo mucho tiempo para infligir daños.
 A10: Caso de Abuso
• Como atacante, ataco a una organización y
los registros, los sistemas de monitoreo y los
equipos no ven ni responden a mis ataques.
 Resumen

• Desarrolle código seguro

– Siga las mejores prácticas (Guía para construir
aplicaciones web seguras)
https://owasp.org/www-pdf-
archive/OWASP_Top_10-2017_%28en%29.pdf.pdf
– Use los OWASP cheat sheets Revise su aplicación
https://cheatsheetseries.owasp.org