Los 10 principales riesgos en aplicaciones web #CPMX5

Los 10 principales
riesgos en
aplicaciones web
(OWASP Top 10 2013)

Sergio Martínez Pacheco
@superserch

Open Web Application Security Project
• Una comunidad libre y abierta enfocada en la
seguridad de las aplicaciones
• OWASP Top Ten 2013
– 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

OWASP Top Ten Agradecimientos
Aspect Security
HP
Minded Security
Softtek
Trustwave, Spiderlabs
Veracode
WhiteHat Security Inc.

Sobre riesgos y no solo vulnerabilidades

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 SQLCapadeaplicaciónCapadeRed
Firewall
Plataforma
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge
Mgmt
E-Commerce
Bus.Functions
Firewall
Base de
Datos
Petición
HTTP

SQL
query

DB Table


Respuesta
HTTP


El atacante usa una forma
para enviar como datos:
‘ OR 1=1 --
La Aplicación reenvía el
ataque a la base de datos:
SELECT * FROM
accounts WHERE
acct=’’ OR 1=1—’
La Base de datos entrega
la información a la
aplicación
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);

accounts WHERE custID='" +
request.getParameter("id") + "'";
PrepareStatement ps = conn.
prepareStatement(query);
ResultSet rs = ps.executeQuery();

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: Más información
• Para mas detalles, se recomienda leer:
https://www.owasp.org/index.php/SQL_Injecti
on_Prevention_Cheat_Sheet

A2: Fallos de Autenticación y manejo
de sessiones
• HTTP es un protocolo “stateless”
– Las credenciales deben viajar con cada petición
– Debería usar SSL 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 SSL para proteger las credenciales y la sesión
siempre

A2: Recomendaciones
• Verificar la Implementación de la aplicación
– Revisar el certificado SSL
– Examinar todas las funciones relacionadas a la
autenticación
– Verificar que el “Salir” en verdad destruya la sesión

A2: Más Información
https://www.owasp.org/index.php/Authentica
tion_Cheat_Sheet

A3: 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

A3: Ejemplo
Sitio Web Vulnerable
1 El Atacante pone una trampa
- Ejemplo en el perfil
2 La victima en la página entra
Al perfil del atacante
Custom Code
Accounts
Finance
Administration
Transactions
Communication
KnowledgeMgmt
E-Commerce
Bus.Functions
El atacante pone un script
malicioso que se guarda
en la base de datos de la
aplicación
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

A3: 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

A3: Contextos de ejecución del HTML
CSS Property Values
(e.g., .pdiv a:hover {color: red; text-decoration:
underline} )
JavaScript Data
(e.g., <script>
someFunction(‘DATO’)</script> )
HTML Attribute Values
(e.g., <input name='persona' type='TEXT'
value=’Valor'> )
HTML Element Content
(e.g., <div> Algún texto a desplegar </div> )
URI Attribute Values
(e.g., <a href=" http://site.com?search=DATO" )
#4: Todos no-alfanumericos < 256  HH
ESAPI: encodeForCSS()
#3: Todos no-alfanumericos < 256  xHH
ESAPI: encodeForJavaScript()
#1: ( &, <, >, " )  &entity; ( ', / )  &#xHH;
ESAPI: encodeForHTML()
#2: Todos no-alfanumericos < 256  &#xHH;
ESAPI: encodeForHTMLAttribute()
#5: Todos no-alfanumericos < 256  %HH
ESAPI: encodeForURL()
Cualquier otro contexto NO DEBE incluir datos no confiables

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

A4: Referencias inseguras a objetos
directos
• ¿Cómo proteges el acceso a tus datos?
– Tiene que ver con A2 y A7
• Errores comunes
– Sólo listo los objetos autorizados al usuario actual
– Escondo las referencias a objetos en campos
ocultos
– … pero no validó estas restricciones en el servidor
• Impacto: Usuarios pueden acceder a archivos o
datos no autorizados

A4: Ejemplo
• El atacante observa que el parámetro cuenta
es A113 - ?cuenta=A113
• Lo modifica con un número cercano -
?cuenta=A114
• El atacante tiene acceso a la información de la
cuenta de la victima
https://www.bancoenlinea.com/misCuentas?cuenta=A113

A4: Recomendaciones
• Eliminar las referencias directas a objetos
– Reemplazar las referencias con valores temporales
• Validar la referencia al objeto
– Verificar el formato del parámetro
– Verificar si el usuario tiene acceso al objeto solicitado
http://app?file=Report123.xls
http://app?file=1
http://app?id=MAXP801204
http://app?id=4r556g3

A5: 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

A5: 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

A6: 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

A6: 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

A6: Ejemplo
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge
Mgmt
E-Commerce
Bus.Functions
Log files
1 La victima da su tarjeta de
crédito para realizar una
reservación
2 Por un error en la
comunicación con el
gateway de pagos, el
sistema logguea el error
junto con la tarjeta
3 Los logs están disponibles a
los miembros del equipo de
desarrollo para debugueo
4 Un empleado
malicioso roba los
números de tarjetas
de crédito

A6: 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

A6: 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?

A6: 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 SSL antes de usarlos

A6: Más Información
• Para mas detalles se recomienda leer:
https://www.owasp.org/index.php/Transport_
Layer_Protection_Cheat_Sheet

A7: Falta de controles de acceso por
función
• ¿Cómo proteger el acceso a las URLs (Páginas)
o funciones referenciadas por un URL y
parámetros?
– Relacionado con A2 y A4
• Impacto
– Poder invocar funciones y servicios para los que no
se está autorizado
– Acceder a la información de otros usuarios
– Realizar acciones privilegiadas

A7: Ejemplo
• 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
https://www.bancoenlinea.com/usuario/obtenerCuentas

A7: 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)

A7: 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

• Para detalles sobre Zed Attack Proxy (ZAP)
https://code.google.com/p/zaproxy/wiki/Intro
duction

A8: Cross Site Request Forgery (CSRF)
• Consiste en engañar al navegador de la victima
para que realice una petición a una aplicación
vulnerable
• La vulnerabilidad es causada por que los
navegadores automáticamente envían
información de autenticación en cada petición
(SESSION ID, IP Address, Windows Domain
Credentials, …)

A8: Imagina …
• ¿Y que tal si un Hacker pudiera mover tu
puntero de ratón y dar click en algunas ligas en
ti aplicación bancaria?
• ¿Qué podrían hacerte hacer?

A8: Ejemplo
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge
Mgmt
E-Commerce
Bus.Functions
El atacante coloca un tag
<img> oculto que contiene
el ataque al sitio
vulnerable
1 El atacante prepara una trampa en un sitio en internet
(o por un correo electrónico)
2 Mientras está firmado en el sitio
vulnerable, la victima ve el sitio del
atacante
Al cargar el tag <img> el
navegador envía un SET
(Incluyendo credenciales)
a la aplicación vulnerable
Aplicación con
vulnerabilidad CSRF
3 El sitio vulnerable ve una
petición legitima de la victima
y realiza la operación que se
solicitó
<img
src=”https://www.bancoenlinea/u
suario/transfiere?ctaDestino=A113
&cantidad=1000" />

A8: Recomendaciones
• Agregar un “secreto” (token) que no se envíe
automáticamente a todas las peticiones
sensibles
• Los Tokens deben ser criptográficamente
fuertes o completamente aleatorios
• No permitas que los atacantes coloquen
ataques en tus sitios
– Codifica adecuadamente todo dato que recibas de
los usuarios

A8: Recomendaciones
• Guardar un Token en la sesión y agregarlo a
todas las formas y ligas
– <input name="token" value="33775a43db221”
type="hidden">
– URL de un solo uso: /cuentas/33775a43db221
– Como parámetro: /cuentas?auth=33775a43db221
• Usar un único token por función
• Usar una doble autenticación para funciones
sensibles

• para más detalles se recomienda leer:
https://www.owasp.org/index.php/CSRF_Prev
ention_Cheat_Sheet

A9: Usar componentes con
vulnerabilidades conocidas
https://www.aspectsecurity.com/news/the-unfortunate-reality-of-insecure-libraries/

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

• En el mundo Java:
https://www.owasp.org/index.php/OWASP_D
ependency_Check
• En .Net
https://github.com/OWASP/SafeNuGet

A10: Redirecciones sin validación
• Las redirecciones son comunes y usualmente
contienen datos generados por el usuario, si no
están validados un atacante puede enviar a un
usuario al sitio de su preferencia
• Los Forwards o include envían la petición a una
nueva página en la aplicación actual.
• Algunas veces los parámetros definen la página
destino
• Si no están validados un atacante podría pasar los
controles de autorización o autenticación

A10: Impacto
• Enviar a una victima a un sitio de phishing o
malware
• Un atacante podría saltase los niveles de
seguridad dentro de la aplicación

A10: Ejemplo
Custom Code
Accounts
Finance
Administration
Transactions
Communication
Knowledge
Mgmt
E-Commerce
Bus.Functions
La petición se envia al sitio
vulnerable, incluyendo el
ataque
From: Servicio de Administración Tributaria
Subject: Devolución de Impuestos
Nuestros registros indican que necesita
aclarar los datos presentados en su
declaración, en la siguiente liga
Sitio falso
1 El atacante envía un
ataque en un correo o
una página a su victima
2 La victima da click al link con el
parámetro sin validación
3 La aplicación redirecciona la
victima al sitio del atacante
4 El sitio del atacante instala
malware o pide información
confidencial

A10: Recomendaciones
• Evitar usar redirecciones y forwards tanto
como sea posible
• Si no, no usar parámetros para definir el URL
destino
• Si debe usar parámetros entonces:
– Validar cada parámetro para asegurarse que es
válido y autorizado
– Usar mapeos del lado del servidor para
transformar la opción provista por el usuario a una
página destino real

Resumen
• Desarrolle código seguro
– Siga las mejores prácticas (Guía para construir aplicaciones
web seguras)
https://www.owasp.org/index.php/Guide
– Use los OWASP cheat sheets
https://www.owasp.org/index.php/Cheat_Sheets
• Revise su aplicación
– Guía para revisiones de código
https://www.owasp.org/index.php/Code_Review_Guide
– Guía de pruebas
https://www.owasp.org/index.php/Testing_Guide

Te Recomendamos:
¿Dónde? ¿Cuándo? ¿Quién? ¿Qué?
Principal 26 Junio
17:00 Hrs
FI-WARE /
INFOTEC
Presentación de la región México de FI-
Lab
Principal 25 Junio
21:00 Hrs
Hugo Estrada Ambientes Inteligentes
Pitágoras 26 Junio
11:00 Hrs
Javier Solís Web Semántica de la teoría a la práctica
Arquímedes 26 Junio
21:00 Hrs
FI-WARE FI-WARE
15:00 Hrs
Jorge Jiménez SWB Social, Maximiza tecnológicamente
el potencial de los medios sociales
10:00 Hrs
Iván Lozada y
Valentín
Gómez
Equipos de trabajo auto dirigidos
enfocados a la calidad de software
basados en la disciplina TSP/PSP
22:00 y
23:00 hrs
Eduardo
Zepeda y
Héctor Cuevas
Hackeando al sexo femenino y SexTeen,
Cuando las personas y la tecnología te
traicionan

Síguenos en nuestras redes sociales:

Los 10 principales riesgos en aplicaciones web #CPMX5

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Los 10 principales riesgos en aplicaciones web #CPMX5

Similar a Los 10 principales riesgos en aplicaciones web #CPMX5 (20)

Más de SemanticWebBuilder

Más de SemanticWebBuilder (12)

Los 10 principales riesgos en aplicaciones web #CPMX5