Date post: | 03-Jul-2015 |
Category: |
Software |
Upload: | semanticwebbuilder |
View: | 362 times |
Download: | 1 times |
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
OWASP Top Ten 2013 Edition
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 SQLC
apa
de
aplic
ació
nC
apa
de
Red
Fire
wal
l
Plataforma
Custom Code
Acc
ou
nts
Fin
ance
Ad
min
istr
atio
n
Tran
sact
ion
s
Co
mm
un
icat
ion
Kn
ow
led
ge
Mgm
tE-
Co
mm
erc
e
Bu
s. F
un
ctio
ns
Fire
wal
l
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);
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: 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 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
• Para mas detalles, se recomienda leer:
https://www.owasp.org/index.php/Authentication_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
Acc
ou
nts
Fin
ance
Ad
min
istr
atio
n
Tran
sact
ion
s
Co
mm
un
icat
ion
Kn
ow
led
ge M
gmt
E-C
om
mer
ce
Bu
s. F
un
ctio
ns
El atacante pone un script malicioso que se guardaen la base de datos de la aplicación
El script corre en el navegador de la victimacon 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
A3: Más información
• Para mas detalles, se recomienda leer:
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.xlshttp://app?file=1
http://app?id=MAXP801204http://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
Acc
ou
nts
Fin
ance
Ad
min
istr
atio
n
Tran
sact
ion
s
Co
mm
un
icat
ion
Kn
ow
led
ge
Mgm
tE-
Co
mm
erce
Bu
s. F
un
ctio
ns
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
A7: Más información
• Para detalles sobre Zed Attack Proxy (ZAP)
https://code.google.com/p/zaproxy/wiki/Introduction
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 DomainCredentials, …)
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
Acc
ou
nts
Fin
ance
Ad
min
istr
atio
n
Tran
sact
ion
s
Co
mm
un
icat
ion
Kn
ow
led
ge
Mgm
tE-
Co
mm
erce
Bu
s. F
un
ctio
ns
El atacante coloca un tag <img> oculto que contieneel ataque al sitiovulnerable
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ó
<imgsrc=”https://www.bancoenlinea/usuario/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
A8: Más información
• para más detalles se recomienda leer:
https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet
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: Más información
• En el mundo Java:
https://www.owasp.org/index.php/OWASP_Dependency_Check
• En .Nethttps://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
Acc
ou
nts
Fin
ance
Ad
min
istr
atio
n
Tran
sact
ion
s
Co
mm
un
icat
ion
Kn
ow
led
ge
Mgm
tE-
Co
mm
erce
Bu
s. F
un
ctio
ns
La petición se envia al sitiovulnerable, incluyendo el ataque
From: Servicio de Administración Tributaria
Subject: Devolución de Impuestos
Nuestros registros indican que necesitaaclarar los datos presentados en sudeclaració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 sheetshttps://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
Arquímedes 27 Junio 15:00 Hrs
Jorge Jiménez SWB Social, Maximiza tecnológicamente el potencial de los medios sociales
Arquímedes 28 Junio 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
Arquímedes 26 Junio 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: