The OWASP Foundationhttp://www.owasp.org

Las diez vulnerabilidades web más relevantes

Eduardo Castellanos

eduardo.castellanos@owasp.org

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