owasp top 10
DESCRIPTION
Presentación en el OWASP Day Guatemala 2011TRANSCRIPT
The OWASP Foundationhttp://www.owasp.org
Las diez vulnerabilidades web más relevantes
Eduardo Castellanos
Eduardo Castellanos
• 3 años de experiencia en desarrollo
• 3 años de experiencia en seguridad
• Analista de seguridad para Verizon Business Security Solutions
• A través de SISAP
• Asociado de (ISC)² orientado a CISSP
• Miembro del capítulo de OWASP Guatemala
Su “perímetro” de seguridad tiene grandes agujeros en la capa de aplicaciones
|3
Fire
wall
SO Endurecido
Servidor Web
Servidor de App
Fire
wall
Bases d
e
dati
sLeg
acy
Syste
ms
Serv
icio
s W
eb
Dir
ecto
rios
RR
HH
Cob
rosCódigo de
Aplicación Elaborado a la
MedidaATAQUE A LA APLICACIÓN
No se pueden utilizar mecanismos de protección de red para detener o detetctar attaques de la capa de aplicación
Ca
pa
de
Red
Ca
pa
de
Ap
lica
cio
ne
s
OWASP Top 10
A1: Inyección A2: Cross-Site Scripting (XSS)
A3: Pérdida de Autenticación y Gestión de
Sesiones
A4: Referencia Directa
Insegura a Objetos
A5: Cross Site Request
Forgery (CSRF)
A6: Defectuosa Configuración de Seguridad
A7: Falla de Restricción de Acceso a URL
A8: Almacenamien
to Criptográfico
Inseguro
A9: Protección Insuficiente en
la Capa de Transporte
A10: Redirecciones y Reenvios no
Validados
A1 – Inyección
• Engañar a la aplicación para que incluya instrucciones adicionales en los datos enviados a un interpretador
¿Qué es?
• Reciben cadenas de caracteres y las ejecutan como instrucciones.• SQL, Shell del SO, LDAP, XPath, Hibernate, etc…
Los interpretadores…
• Muchas aplicaciones todavía son suceptibles• Aunque es muy fácil de evitar
La inyección SQL aún es bastante común
• Usualmente severo.
Impacto
Ejemplo: ataque de inyección SQL
Select user_information from user_table where username='input username' and password='input password'
Web Server Application Server
User DatabaseUser
https
Select user_information from user_table where username= '' or 1=1 -- ' and password='abc'
¿Comodo?
Marzo 2011
• Un hacker usó inyección SQL para entrar a un sistema de un afiliado de Comodo.
• Comodo es un CA. Ellos firman certificados SSL para garantizar la seguridad de las comunicaciones.
Resultado
• El hacker obtuvo las credenciales paraentrar a los sistemas para generar certificados.
• Generó certificados para mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org y login.live.com
A1 – Evitando la Inyección
Recomendaciones
1. Evitar usar un interprete, o
2. Usar una interfaz que permita atar (bind) variables (e.g., prepared statements, o stored procedures)
3. Codificar todas las entradas del usuario antes de pasarlas al interprete.
Referencias
• SQLi Prevention Cheat Sheet http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
A2 – Cross-Site Scripting (XSS)
• Datos sin filtrar del atacante se le envían al navegador de la víctima.
Ocurre cuando…
• Se guardan en una BD, se reflejan, o se usan en JavaScript
Los datos sin filtrar…
• Conocida desde antes del 2000
Es una vulnerabilidad increiblemente común.
• Moderado
Impacto
XSS = Cross-site Scripting
Vulnerabilidad de las aplicaciones web
Permite la inyección de código en páginas que serán vistas por otros usuarios
XSS = el nuevo buffer overflow
Javascript = el nuevo Shell Code
11
Samy Worm
• Primer Worm de XSS
• Escrito por Samy Kamkar
• Afectó a MySpace.com
En menos de 20 horas afectó a más de 1 millón de usuarios
12
Browser Exploitation Framework
(AntiSamy)
A2 – Evitando XSSRecomendaciones
• Eliminar la falla
• Defenderse de la falla
• Recomendación principal: Codificar todas las salidas que contengan datos proporcionados por el usuario (Usar OWASP’s ESAPI)
http://www.owasp.org/index.php/ESAPI
• Para grandes porciones de HTML:
• OWASP’s AntiSamyhttp://www.owasp.org/index.php/AntiSamy
Referencias
• Cross-site Scripting Cheat Sheethttp://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet
A3 – Pérdida de Autenticación y Gestión de Sesiones
• Las credenciales deben ir en cada petición
HTTP es un protocolo “sin estado”
• Un ID de SESION se usa para llevar los estados
Fallas de la gestión de sesiones
• Cambiar mi password, recordar password, pregunta secreta, logout, etc…
Cuidado con las puertas traseras…
• Severo.
Impacto
Ataque de Fijación de Sesión
A3 – Evitando la Pérdida de Autenticación y Gestión de Sesiones
Verificar la arquitectura
• La autenticación debe ser simple, centralizada y estandarizada.
• Use el identificador de sesión proporcionado por el contenedor
• Asegurese que las credenciales y el identificador de sesión estan protegidos con SSL todo el tiempo.
Verificar la implementación
• Verificar que el cierre de sesión la destruya.
• Verificar las funciones de autenticación
Authentication Cheat Sheet
• http://www.owasp.org/index.php/Authentication_Cheat_Sheet
A4 – Referencia Directa Insegura a Objetos
• Esto es parte de aplicar correctamente la “Autorización”
¿Cómo protege el acceso a sus datos?
• Mostrar únicamente objetos ‘autorizados’ para el usuario
• Ocultar las referencias a objetos en campos escondidos
• Control a nivel de la capa de presentación: no funciona
Un error común…
• Moderado
Impacto
Ejemplo:Referencia Directa Insegura a Objetos
El atacante se da cuenta que el identificador de su cuenta es 6534
?acct=6534
Lo cambia a un numero similar…
?acct=6535
El atacante puede ver la información de la víctima
https://www.onlinebank.com/user?acct=6534
A4 – Evitando la Referencia Directa Insegura a Objetos
• Eliminar la referencia directa
• Hacer un mapeo temporal (1,2,3)
• ESAPI provee esta funcionalidad: IntegerAccessReferenceMap & RandomAccessReferenceMap
• Validar la referencia directa
• Verificar los permisos del usuario
A5 – Cross Site Request Forgery (CSRF)
• Es un ataque en el cual se engaña al navegador de la víctima para que ejecute una instrucción en una aplicación vulnerable
• La información de la autenticación se envía automáticamente
Cross Site Request Forgery
• Un atacante pudiera mover el mouse y hacer click• ¿Qué podrían hacerlo hacer?
Imaginense…
• Moderado
Impacto
Ejemplo: CSRFEl atacante arma una trampa en algun website en
Internet
Una etiqueta <img> contiene el ataque contra
el sitio vulnerable
Mientras esta en una sesión en el sitio vulnerable, la víctima visita el sitio malo
<img src=http://bank.com/transferir?cuenta=2323&cantidad=10000&dest=4444 />
Aplicación con vulnerabilidad
CSRF
El sitio vulnerable mira una petición vulnerable de la
víctima y ejecuta la acción solicitada
A5 – Evitando CSRF
• Agregar un token a cada petición
• Requerir confirmación con la contraseña u otro método
CSRF Cheat Sheet
• www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet
A6 – Defectos en la Configuración de Seguridad
• Plataforma, servidor web, servidor de app, framework o código.
Se puede dar a cualquier nivel del stack
• Parches• Cuentas default• Servicios innecesarios• Archivos de prueba
Gestión de seguridad a lo largo de la aplicación
• Moderado
Impacto
Hardened OS
Web Server
App Server
Framework
Defectos en la Configuración de Seguridad
App Configuration
Custom Code
Acc
ounts
Fin
ance
Adm
inis
trati
on
Transa
ctio
ns
Com
mun
icati
on
Know
ledge M
gm
t
E-C
om
merc
e
Bus.
Funct
ion
s
Test Servers
QA Servers
Source Control
Development
BD
Atacante
A6 – Evitando Defectos en la Configuración de Seguridad
• Verificar la gestión de la configuración
• Seguir una guía de configuración segura
• Establecer un control de cambios
• Verificar la implementación
• Escaneos
A7 – Almacenamiento Criptográfico Inseguro
• No se identifica la información sensible• No se identifican todos los lugares donde pasa la
información• No utilizar bien el cifrado
Almacenanar información sensible sin cifrado
• Severo
Impacto
28
Cifrar información de clientes
Información de clientes, 77 Milliones comprometidos.(probablemente tarjetas de crédito también)
A7 – Evitando Almacenamiento Criptográfico Inseguro
• Considere las amenazas y los datos sensibles
• Asegurese que las copias de los datos estan debidamente protegidas
• Asegurese de usar correctamente algorítmos estándares con llaves fuertes
• Almacene las contraseñas con un hash + sal
A8 – Falla de Restricción de Acceso a URL
• Es importante validar correctamente la autorización
¿Cómo protege el acceso a URLs (páginas)?
• Mostrar únicamente enlaces válidos en los menús• A esto se le conoce como control a nivel de la capa de
presentación, y no funciona.• Un atacante simplemente navega directo a las páginas
Un error común…
• Los atacantes realizan funciones sin autorización• Acceden a datos de usuarios• Realizan acciones privilegiadas
Impacto
Ejemplo de Falla de Restricción de Acceso a URL
El atacante se da cuenta que el URL define su rol
/user/getAccounts
Lo cambia a otro directorio (rol)
/admin/getAccounts, o
/manager/getAccounts
El atacante mira las cuentas de otros usuarios
https://www.onlinebank.com/user/getAccountshttps://www.onlinebank.com/user/getAccounts
A9 – Protección Insuficiente en la Capa de Transporte
• No se identifica toda la información sensible• No se identifica por donde pasa esta información
• En internet, hacia las bases de datos, hacia socios de negocio, comunicación interna
Transmitiendo información sensible sin cifrado
• Un atacante accede o modifica información confidencial
• Pérdida de imagen y confianza en la empresa, clientes insatisfechos
• Costo de contener el incidente• Multas o demandas
Impacto
33
Firesheep
OWASP - 2010
A9 – Evitando Protección Insuficiente en la Capa de Transporte Proteger con mecanismos adecuados
Usar TLS en todas las conexiones con información sensible
Cifrar mensajes previo a su transmisión
Usar los mecanismos adecuadamente No usar cifrados SSL obsoletos Atributo Secure de las cookies Gestionar las llaves/certificados adecuadamente Usar mecanismos comprobados
Cheat Sheet: http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
A10 – Redirecciones y Reenvíos No Validados
• Parámetros en el URL• Si no se validan, el atacante puede redirigir
arbitrariamente
Los redireccionamientos son bastante comunes
• Redirigir a la víctima a un sitio malvado• Facilitar ataques de phishing y robo de credenciales
Impacto
CNN
http://ads.cnn.com/event.ng/Type=click&Redirect=http:/bit.ly/cP–XW
36
OWASP - 2010
A10 – Evitando Redirecciones y Reenvíos No ValidadosVarias opciones
1. Evitar usarlos2. No usar parámetros para determinar el URL3. Si ‘debe’ tener parametros
a) Validar que cada parámetro sea válido. b) (preferido) – Usar un mapeo del lado del
servidor ESAPI
Ver: SecurityWrapperResponse.sendRedirect( URL )
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/filters/SecurityWrapperResponse.html#sendRedirect(java.lang.String)
OWASP - 2010
Resumen: ¿Cómo atacar estos problemas? Desarrollar código seguro
Seguir las mejores prácticas definidas en OWASP’s Guide to Building Secure Web Applications
http://www.owasp.org/index.php/Guide Usar OWASP’s Application Security Verification Standard
http://www.owasp.org/index.php/ASVS Usar componentes de seguridad
Usar OWASP’s ESAPI como la base para SUS componentes http://www.owasp.org/index.php/ESAPI
Revisar las aplicaciones Que un equipo de expertos revise sus aplicaciones Revise sus aplicaciones por si mismo usando guías OWASP
OWASP Code Review Guide: http://www.owasp.org/index.php/Code_Review_Guide
OWASP Testing Guide: http://www.owasp.org/index.php/Testing_Guide
Descarguen
http://www.owasp.org/index.php/Top_10
www.owasp.org
|40
40
41
Suscribanse a nuestra lista de correo
https://lists.owasp.org/mailman/listinfo/owasp-Guatemala