OpenSouthCode '18 - OWASP Top 10 (2017) [2018-June-01]

OWASP
Top 10 (2017)
Repaso a las 10 principales vulnerabilidades de
seguridad en aplicaciones web
OPENSOUTHCODE 2018
ÁNGEL GÓMEZ ROMERO
1 DE JUNIO 2018

Copyright © 2018 Accenture. Todos los derechos reservados
2
ÁNGEL GÓMEZ ROMERO
Accenture Technology Center in Spain
@a_gomez_r
MálagaJUG
BoquerónSec
Advanced App Engineering Specialist en Accenture. 15+ años desarrollando,
diseñando e involucrado en arquitectura en diferentes lenguajes (principalmente
en Java). DevOps practicante, amante de las soluciones en Cloud y evangelista de
la aplicación de la Seguridad de Aplicaciones en el SDLC (Ciclo de Desarrollo del
Software).

3
• INTRODUCCIÓN
• FACTORES DE RIESGO
• OWASP TOP 10 (2017)
• CONCLUSIÓN
• REFERENCIAS
I
RISK
T10
+C
+R

4
• Acerca de OWASP
• ¿Principales cambios de 2013 a
2017?
I

5
El Proyecto Abierto de Seguridad en Aplicaciones Web (OWASP por sus siglas en
inglés) es una comunidad abierta dedicada a permitir que las organizaciones
desarrollen, adquieran y mantengan aplicaciones y APIs en las que poder confiar
OBJETIVO OWASP TOP 10
Originalmente el objetivo del proyecto OWASP Top 10 fue simplemente concienciar a los
desarrolladores, diseñadores, arquitectos, gerentes y organizaciones sobre las
consecuencias de las debilidades más comunes y más importantes de la seguridad de las
aplicaciones web, pero con el paso del tiempo se ha convertido en un standard de seguridad
de facto.
OWASP TOP 10 (2017)
El Top 10 es un documento que proporciona técnicas básicas para protegerse contra las 10 áreas identificadas con
problemas de alto riesgo identificadas por OWASP, y proporciona orientación sobre cómo continuar desde allí.
Se basa principalmente en el envío de datos de más de 40 empresas que se especializan en seguridad de aplicaciones y una
encuesta de la industria que fue completada por más de 500 personas. Esta información abarca vulnerabilidades recopiladas
de cientos de organizaciones y más de 100.000 aplicaciones y APIs del mundo real.
Las 10 principales categorías fueron seleccionadas y priorizadas de acuerdo con estos datos de prevalencia, en
combinación con estimaciones consensuadas de explotabilidad, detectabilidad e impacto.
I

6
El escenario de amenazas para la seguridad en aplicaciones cambia de manera
constante, principalmente debido a la aparición de nuevas técnicas para realizar
ataques web, así que OWASP Top 10 continuará cambiando
I

7
• ¿Cuáles son los riesgos en
seguridad de aplicaciones?
• ¿Cómo se mide el riesgo en el
OWASP Top 10?
• Resumen factores de riesgo
RISK

8
Los atacantes pueden, potencialmente, utilizar diferentes rutas a través de una
aplicación para perjudicar un negocio u organización. Cada uno de estos caminos
representa un riesgo que puede o no ser suficientemente grave para atenderlo
RISK

9
Para cada categoría del Top 10, se estima el riesgo de cada vulnerabilidad en una
aplicación web, observando los factores de probabilidad comunes y de impacto (sin
tener en cuenta probabilidad del agente de amenaza o impacto real sobre negocio)
RISK

10
RISK

11
• 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 VULNERABLES
• A10:2017 REGISTRO Y MONITORIZACIÓN INSUFICIENTES
T10

12
Ocurre cuando se envían datos no confiables a un intérprete, como parte de un comando o
consulta, engañando al intérprete para que ejecute comandos involuntarios o acceda a los
datos sin la debida autorización
A1
:2017
¿CÓMO PREVENIRLO?
1. Se debe verificar que se haga una separación de la información no
confiable del comando o consulta. Para llamadas SQL usar variables
parametrizadas en todos los “prepared statements“ y procedimientos
almacenados, evitando las consultas dinámicas.
2. Preferible usar una API segura evitando el uso de intérpretes, o si no
es posible, codificar cuidadosamente caracteres especiales.
3. Realizar validación de entradas de lista blanca.

13
La autenticación y gestión de sesiones son implementadas incorrectamente, permitiendo a
los atacantes comprometer usuarios y contraseñas, token de sesiones para asumir (temporal
o permanentemente) la identidad de otros usuarios
A2
:2017
¿CÓMO PREVENIRLO?
1. Uso de autenticación multi-factor y sin contraseñas por defecto.
2. Limitar/incrementar el tiempo de respuesta de cada intento fallido de
inicio de sesión, usando mensajes genéricos en las salidas y
registrando todos los fallos para avisar en ataques de fuerza bruta.
3. Implementar controles contra contraseñas débiles (ej. puede
verificarse contra la lista Top 10.000 de peores contraseñas).
3. Alinear política de longitud, complejidad y rotación de contraseñas
con recomendaciones modernas.
4. Generar un nuevo ID de sesión aleatorio, no incluido en la URL e
invalidado después del cierre de sesión o inactividad (aplicando
política de rotación).

14
Los datos sensibles sobre información financiera, de salud, etc. requieren métodos de
protección adicionales, siendo susceptibles de fraudes en tarjetas de crédito o robos de
identidad mediante ataques Man in the Middle
A3
:2017
¿CÓMO PREVENIRLO?
1. No almacenar datos sensibles innecesariamente, descartar tan
pronto sea posible (los datos no almacenados no pueden ser
robados), y al guardarlos deben estar cifrados.
2. Asegurar que las claves se guardan con algoritmos de hashing
estándares y fuertes como Argon2, scrypt, bcrypt o PBKDF2 (no
obsoletos como MD5, SHA1 y no algoritmos de cifrado propios).
3. Deshabilitar autocompletar en los formularios que recolectan datos
sensibles, así como el guardado en caché.
4. Establecer encabezados de seguridad para el navegador web.
5. Verificar mediante User-Agent del usuario (aplicación o cliente de
correo) que el certificado enviado por el servidor es válido.

15
Se explotan procesadores XML vulnerables si cargan o incluyen contenido no validado,
revelando archivos internos en servidores, escaneando puertos de la LAN, ejecutando
código de forma remota y ataques de denegación de servicio (DoS)
A4
:2017
¿CÓMO PREVENIRLO?
1. Utilizar formatos de datos menos complejos como JSON y evitar la
serialización de datos confidenciales.
2. Actualizar procesadores y bibliotecas XML, utilizando validadores de
dependencias, así como SOAP en versión 1.2 o superior.
3. Deshabilitar las entidades externas de XML y procesamiento DTD en
todos los analizadores sintácticos XML de la aplicación.
4. Usar "lista blanca", filtrado y sanitización datos dañinos en
documentos, cabeceras y nodos XML (también validación XSD).
5. Herramientas SAST detectan XXE en código fuente, aunque revisión
manual es mejor en aplicaciones grandes y complejas.

16
Las restricciones sobre lo que los usuarios autenticados pueden hacer no se aplican
correctamente. Los atacantes no autorizados podrían acceder a cuentas de otros usuarios,
modificar datos, pudiendo cambiar derechos de acceso y permisos, etc.
A5
:2017
¿CÓMO PREVENIRLO?
1. Denegar de manera predeterminada (excepto recursos públicos).
2. Exigir la propiedad de un registro al usuario, en lugar de aceptar que
pueda crear, leer, actualizar o eliminar cualquier registro.
3. Deshabilitar listado directorios en servidor web, y asegurar que
metadatos/fuentes archivos (GIT) no están en carpetas públicas.
4. Registrar errores de control de acceso, limitar la tasa de acceso a las
APIs y alertar a administradores (ej. fallos reiterados).
5. Los desarrolladores y QAs deben incluir pruebas de control de
acceso en sus pruebas unitarias y de integración.

17
En parte por hacerla de manualmente, ad hoc o por omisión (S3 buckets abiertos),
cabeceras HTTP incorrectas, mensajes de error con contenido sensible, falta de parches y
actualizaciones en frameworks, dependencias y componentes, etc.
A6
:2017
¿CÓMO PREVENIRLO?
1. Proceso rápido, fácil y repetible de hardening que agilice y facilite la
configuración de la seguridad (la misma en desarrollo, QA y
producción).
2. Uso de plataforma minimalista sin elementos innecesarios, borrar o
no instalar frameworks y funcionalidades no utilizadas.
3. Evitar dejar activas cuentas por defecto y sus contraseñas
habilitadas y sin modificar.
4. Forzar que el manejo errores no revele rastros o mensajes
demasiado informativos.
3. Enviar directivas de seguridad a los clientes (ej. cabeceras de
seguridad).
4. Ejecutar escaneos y realizar auditorías periódicamente para ayudar a
detectar fallos de configuración o parches omitidos.

18
Se envían datos no confiables al navegador web sin una validación y codificación apropiada,
o actualiza una página web existente con datos suministrados por el usuario utilizando una
API que ejecuta JavaScript en el navegador
A7
:2017
¿CÓMO PREVENIRLO?
Segunda vulnerabilidad más frecuente en OWASP Top 10 (un tercio de
las aplicaciones), pero con menos peso porque disponemos de kits de
explotación (gratuitos) para detectarla, particularmente en tecnologías
maduras como PHP, J2EE / JSP, y ASP.NET.
Prevenir XSS requiere mantener los datos no confiables separados del
contenido activo del navegador.
1. Utilizar frameworks seguros que, por diseño, codifican contenido
para prevenir XSS, como Ruby 3.0 o React JS.
2. Codificar datos no confiables en los campos de salida HTML (cuerpo,
atributos, JavaScript, CSS, o URL).
3. Validar entradas positivas o de “lista blanca”.

19
Se reciben objetos serializados dañinos que pueden ser manipulados o borrados por el
atacante para realizar ataques de repetición, inyecciones o elevar sus privilegios de
ejecución. En el peor de los casos, la ejecución remota de código en el servidor
A8
:2017
¿CÓMO PREVENIRLO?
El único patrón de arquitectura seguro es no aceptar objetos serializados
no confiables o sólo permitir tipos de datos primitivos.
1. Verificar integridad con firmas digitales en objetos serializados, con el
fin de detectar modificaciones no autorizadas.
2. Aplicar restricciones de tipo estrictas durante la deserialización antes
de la creación de objetos, ya que el código suele esperar un conjunto
de clases definibles.
3. Aislar el código que realiza la deserialización, de modo que se
ejecute en un entorno con los mínimos privilegios posibles.
4. Restringir excepciones, monitorizar conexiones (I/O) de red,
alertando si un usuario deserializa constantemente.
Se ha incluído en el OWASP Top 10 a partir de las
sugerencias de la industria y no está basado en datos
cuantificables (se espera que crezca y vaya apareciendo
como vulnerabilidad en aplicaciones).
Difícil explotarla al necesitar cambios o ajustes en el
código fuente.

20
Los componentes como bibliotecas, frameworks y otros módulos se ejecutan con los mismos
privilegios que la aplicación. Explotando un componente vulnerable se debilitan las defensas
de aplicaciones y APIs permitiendo diversos ataques
A9
:2017
¿CÓMO PREVENIRLO?
1. Evitar usar software vulnerable, sin soporte o desactualizado (incluye
el SO, servidor web o de aplicaciones, DBMS, APIs y componentes)
y parchear o actualizar la plataforma, frameworks y dependencias
anidadas.
2. Analizar los componentes periódicamente, siguiendo los boletines de
seguridad de los componentes utilizados.
3. Eliminar dependencias, funcionalidad innecesaria/no usada.
4. Conocer versiones componentes (ej. OWASP Dependency Check,
retire.js).
3. Obtener componentes únicamente de orígenes oficiales.

21
Junto a la falta de respuesta ante incidentes permiten a los atacantes mantener el ataque en
el tiempo, manipular otros sistemas y extraer o destruir datos. El tiempo de detección de una
brecha de seguridad según IBM era 191 días de media en 2017
A10
:2017
También incluída en el OWASP Top 10 basado en la
encuesta a la industria.
Una estrategia para conocer la monitorización será
examinar los registros después de las pruebas de
penetración.
¿CÓMO PREVENIRLO?
1. Asegurar que errores de inicio de sesión, control de acceso y
validación de entradas en servidor se registran e identifican cuentas
sospechosas. Mantener tiempo suficiente para realizar un posterior
análisis forense.
2. Adoptar un plan respuesta incidentes, como NIST 800-61 rev.2.
3. Registros generados en un formato fácilmente consumible por
soluciones de administración de registros centralizadas.
4. Transacciones de alto impacto se auditan con controles de integridad
para prevenir alteraciones o eliminaciones.
1. Se hacen pruebas de penetración y escaneos con herramientas
DAST (como OWASP ZAP), estableciendo monitorización y alerta
para que actividades sospechosas sean detectadas y respondidas
en tiempos aceptables.

22
• Próximos pasos para:
• DESARROLLADORES Y TESTERS
• ORGANIZACIONES
• ADMINISTRADORES DE APLICACIONES
+C

23
Para ayudar a los desarrolladores, testers, organizaciones y administradores de aplicaciones
a reducir los riesgos de seguridad de sus aplicaciones de un modo
rentable, OWASP ha definido pasos a considerar y recursos gratuitos y abiertos
DESARROLLADORES
Establecer y utilizar procesos de seguridad repetibles y
controles estándar de seguridad:
• Requisitos de Seguridad en Aplicaciones.
• Arquitectura de Seguridad en Aplicaciones.
• Controles de Seguridad Estándar.
• Ciclo de vida de desarrollo software (SDLC) seguro.
• Educación de la Seguridad en Aplicaciones.
ORGANIZACIONES
Comenzar cuanto antes un programa de seguridad en
aplicaciones:
• Documentar seguridad en todas las aplicaciones.
• Enfoque basado en el catálogo de riesgos.
• Contar con una base sólida de políticas y estándares.
• Integrar la Seguridad en los procesos existentes.
• Proporcionar visibilidad a la gestión.
TESTERS
Establecer revisiones continuas de seguridad en las
aplicaciones.
• Comprender Modelo de Amenazas y las prioridades.
• Comprender SDLC (ciclo de vida desarrollo software).
• Estrategia de pruebas simple, rápida y precisa.
• Lograr cobertura y precisión, ampliando con el tiempo.
• Comunicar los mensajes claramente.
ADMINISTRADORES DE APLICACIONES
Administrar el Ciclo de Vida Completo de la Aplicación:
• Administración de Requisitos y Recursos.
• Solicitud de Propuestas (RFP) y Requerimientos.
• Negociar Planificación y Diseño con desarrolladores.
• Despliegue, Pruebas y puesta en Producción.
• Operación y Gestión del cambio en la seguridad.
• Retirada de Sistemas (datos almacenados/eliminados).
+C

24
• Proyecto OWASP Mutillidae 2
• Enlaces de interés
+R

25
Se trata de una aplicación web vulnerable gratuita y OpenSource para realizar pruebas de
Seguridad Web, y puede ser instalada en Linux o Windows utilizando LAMP, WAMP y
XAMPP, así como corre sobre una imagen Docker
Es un entorno para hacking web fácil de utilizar, para entusiastas de la seguridad, diseñado para el uso en talleres, laboratorios
y herramientas para la evaluación de vulnerabilidades o entrenamiento para empresas, con el objetivo de evaluar diverso
software de seguridad.
PUESTA EN MARCHA CON DOCKER
https://hub.docker.com/r/citizenstig/nowasp
• Pull imagen:
docker pull citizenstig/nowasp
• Inicio imagen:
docker run -d 80:80 –t citizenstig/nowasp
• Mostrará error BBDD desconectada, pulsar enlace
para configurar:
setup/reset the DB
+R

26
+R
OWASP TOP 10 MOST CRITICAL WEB APPLICATION SECURITY RISKS
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
CWE/SANS Top 25 Most Dangerous Software Errors
http://cwe.mitre.org/top25
OWASP TESTING PROJECT
https://www.owasp.org/index.php/OWASP_Testing_Project
OWASP MUTILLIDAE 2 PROJECT
https://www.owasp.org/index.php/OWASP_Mutillidae_2_Project

27

OpenSouthCode '18 - OWASP Top 10 (2017) [2018-June-01]

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a OpenSouthCode '18 - OWASP Top 10 (2017) [2018-June-01]

Similar a OpenSouthCode '18 - OWASP Top 10 (2017) [2018-June-01] (20)

Último

Último (18)

OpenSouthCode '18 - OWASP Top 10 (2017) [2018-June-01]