Presentación realizada en el HackLab Cordoba 2011. No pude hacerla entera....

1. Miguel Ángel Arroyo Moreno
Carlos García García
Juan José Rider Jiménez
I Hacklab en Córdoba · www.hacklabcordoba.com

2. Algo sobre mi
 Profesional desde 2001.
 Experto en e-commerce: Verified By VISA,
SecureCode, etc.
 OWASP member desde 2010. Miembro del Spain
Chapter.
 Fundador empresa www.wul4.es
 Twitter: @jjriderWul4
 Email: jjrider@wul4.es / juan.rider@owasp.org
2

3. Algo sobre OWASP
El proyecto abierto de seguridad en aplicaciones Web
(OWASP por sus siglas en inglés) es una comunidad
abierta y libre de nivel mundial enfocada en mejorar la
seguridad en las aplicaciones de software.
Nuestra misión es hacer la seguridad en aplicaciones
"visible", de manera que las organizaciones pueden
tomar decisiones sobre los riesgos en la seguridad de
aplicaciones.
Todo el mundo es libre de participar en OWASP y todos
los materiales están disponibles bajo una licencia de
software libre y abierto.
http://www.owasp.org
3

4. ¿Para qué sirve el OWASP Top 10?
 La madre del cordero:
 No se construyen web
seguras a menos que se
conozca cómo atacarlas
 El Problema:
 Para el 99% de los desarrolladores
los tests de seguridad son un arte oscuro
 La solución?
 Formación básica y conocimiento de posibles ataques

5. OWASP Top 10
A1 Ataques de inyección (SQL inyection, etc)
A2 Cross-Site Scripting (XSS)
A3 Gestión de sesiones y ataques contra la autenticación
A4 Exposición de referencias a objetos de forma directa =
A5 Cross-Site Request Forgery (CSRF) =
A6 Errores de configuración de la seguridad NEW
A7 Errores al restringir accesos a URLs
A8 Redirects y Forwards no validados NEW
A9 Almacenamiento criptográfico inseguro
A10 Comunicaciones inseguras

6. ¿Cómo se calcula el OWASP Top 10?
Threat Attack Weakness Weakness
Technical Impact Business Impact
Agent Vector Prevalence Detectability
1 Easy Widespread Easy Severe
? 2 Average Common Average Moderate ?
3 Difficult Uncommon Difficult Minor
1 2 2 1
A1-Inyección 1.66 * 1
6
1.66 weighted risk rating

7. A1: Ataques de inyección
En qué consiste…
Mandar información a una aplicación y que ésta la interprete como parte de
un comando, ya sea SQL, de sistema, LDAP, etc.
Campos de acción
Casi cualquiera que imaginemos… SQL, LDAP, XPath, ORM(Hibernate, etc),
OS, etc.
Impacto
Severo. En el caso de PCI tenemos que tener especial cuidado en el acceso a los
datos y en el control de acceso a las aplicaciones que muestran datos de
tarjeta.

8. A1: Ataques de inyección
"SELECT * FROM
Account Summary
accounts WHERE
Account:
Knowledge Mgmt
Communication
Administration
Bus. Functions
Legacy Systems
Human Resrcs
Application Layer
E-Commerce
Transactions
Web Services
acct=‘’ OR 1=1--
SKU::
Directories
Accounts Acct:5424-6066-2134-4334
Databases
Finance
HTTP
Billing
HTTP SQL DB Table Acct:4128-7574-3921-0192
response 
’"
request query Acct:5424-9383-2039-4029

APPLICATION
  Acct:4128-0004-1234-0293

ATTACK

Custom Code
1. Se presenta un formulario al
atacante
2. Se envía el ataque enviando
datos ‘no-esperados’
App Server
3. La aplicación reenvia esos
Web Server
datos embedidos en una SQL
Hardened OS
Network Layer
4. La BD ejecuta la query y
devuelve todos los datos a la
aplicación
Firewall
Firewall
5. La aplicación toma los datos
y se los devuelve al atacante

9. A1: Ataques de inyección
Cómo evitarse
1. Evitar el uso de interpretes. Esto nomalmente no es posible.
2. Usar un interfaz para acceder a estos interpretes que permita
el ‘binding’ de estos valores. Ej: PreparedStatements o Stored
Procedures.
3. Codificar/Validar todas las entradas antes de pasarlas al
intérprete.
• Uso de ‘listas blancas’
• Limitar privilegios de acceso a los datos(Usuario de BD)
• ESAPI.Encoder
Solución: Uso de filtros HTTP de validación en base a Patrones
y PreparedStatements.
Más info:
http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

10. A2: Cross-Site Scripting (XSS)
En qué consiste…
Cuando se le devuelve a un usuario un script previamente introducido por un
atacante. El usuario ‘confia’ en el portal.
Campos de acción
En aplicaciones donde lo que uno escribe/envía, otro lo recibe, etc.
Varios tipos:
1. Directo(El script puede encontrarse en BD)
2. Indirecto o reflejado (La web usa un parámetro de entrada en la respuesta)
3. XST(Cross Site Tracing) que usa el método TRACE de HTTP para obtener
las credenciales de usuario ‘Basic-Auth’
Impacto
Severo. Desde obtener el identificador de sesión y reenviarlo de forma
silenciosa a un atacante como instalar un proxy en el navegador para
observar todo el tráfico.

11. A2: XSS
1 Supongamos que existe un servicio de ‘buzón’ de administrador
Aplicación con
vulnerabilidad XSS
El atacante envia el
script en el mensaje
que se almacena en BD
Communication
Administration
Bus. Functions
E-Commerce
Transactions
Knowledge
Accounts
2 El administrador visualiza el mensaje
Finance
Mgmt
Custom Code
El script se interpreta
con los privilegios y
permisos del
administrador
3 El Script envía la cookie de sesión al atacante

12. A2: XSS
Cómo evitarse
1. Evitar devolver los valores de entrada en la página de salida. Ni
incluir los valores recogidos.(esto es imposible en muchos casos)
2. Escaneos periódicos
3. Para defendernos, codificar/validar todas las entradas de usuario
usando listas blancas, ESAPI, y en el caso de tener que incluir
grandes cantidades de HTML, usar AntiSamy.
http://www.owasp.org/index.php/ESAPI
http://www.owasp.org/index.php/AntiSamy
Solución: Uso de validaciones en base a Patrones. Uso de librerias
de OWASP ESAPI y AntiSamy
String safe = ESAPI.encoder().encodeForJavaScript( request.getParameter( "input" ) );
Más info:
http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_S
heet

13. A3: Sesiones y autenticación
En qué consiste…
En obtener los datos de autenticación del usuario(LDAP) o bien su
identificador de sesión(JSESSIONID)
Cómo se obtienen
1. HTTP es un protocolo sin-estado. Las credenciales viajan en TODA petición.
 Se debe usar protocolo seguro siempre que se envíen.
2. Accediendo a logs que contienen el identificador de sesión.  El
identificador de sesión NO debe almacenarse en logs, ni usar reescritura de
URLs…
3. Ataques de ‘session fixation’  Si un ID de sesión no es válido, no darle
validez
4. Mediante sistemas de autologin, remember-me, recordatorios de password
con email, etc.
5. Obtener las sesiones persistentes  Destruir la sesión y tiempos de vida
cortos(15minutos)
Impacto
Severo. Apropiación indebida de los privilegios de usuario.

14. A3: Sesiones y autenticación
1 Usuario envía credenciales
Administration
Communicatio
Bus. Functions
www.boi.com?JSESSIONID=9FA1DB9EA...
Transactions
E-Commerce
Knowledge
Accounts
Finance
Mgmt
n
Aplicación usa reescritura de 2
URLs
Custom Code
3 El usuario cierra el browser y deja su PC
5 El hacker usa el id de 4 El hacker accede al PC y busca
sesión y toma el control en el historico de navegación
de la sesión

15. A3: Sesiones y autenticación correo o un
El hacker envía un
1
link a un usuario registrado con
un id de session generado por él
www.boi.com?JSESSIONID=9FA1DB9EA...
El usuario accede a la aplicación y se
autentica
2
Knowledge Mgmt
Communication
Administration
Bus. Functions
Transactions
E-Commerce
Accounts
Finance
La aplicación admite el id de sesión porque
cumple sus patrones
3
Custom Code
Aplicación usa reescritura d
URLs
4 El hacker usa el id de
sesión y toma el control
de la sesión

16. A3: Sesiones y autenticación
Cómo evitarse
1. Verificar la arquitectura
• Debe ser simple, centralizada y estandarizada (Ej. LDAP)
• Asegurarse que tanto el id de sesión como las credenciales
siempre viajan seguras
2. Verificar la implementación
• Examinar todas las funciones de creación/destrucción de
sesiones y comprobación de usuario.
• Verificar que el logout destruye la sesión
3. Escaneos periódicos
Solución: Muchas opciones.

17. A4: Referencias inseguras a objetos
En qué consiste…
Hay que proteger el acceso a los datos. En una aplicación web esto implica
acceso a opciones de menú, URLs, etc. Esto está en consonancia con el 6.5.7.
The ‘schoolboy mistake’
• Ocultar las referencias en campos hidden.
• Sólo mostrar los objetos a los que tiene acceso el usuario(menús, botones,
etc)
• Realizar comprobaciones en el cliente …. Y luego no hacerlo en el servidor
• Usar un valor de un parámetro (lista de valores) para acceder a una
funcionalidad.
Aplicaciones vulnerables
Aquellas que reciben como parámetro el procedimiento remoto a ejecutar….
Impacto
Implica ciertos conocimientos de la aplicación a atacar. Acceso no autorizado a
datos/operaciones.

18. A4: Referencias inseguras a objetos
Como veo que un
https://www.onlinebank.com/user?acct=6065 campo es el ‘acct’
con valor 6065…
pruebo el 6066
Y bingo!
Ya tengo acceso a
otra cuenta.

19. A4: Referencias inseguras a objetos
Cómo evitarse
1. Eliminar el método de acceso usando una referencia fija Se
pueden usar referencias ‘temporales’(ESAPI proporciona esa
funcionalidad)
2. Validar la referencia al objeto
• Validar el formato de la referencia
• comprobar que el usuario realmente tiene privilegios(filtros,
Spring Security, etc)
3. Cuidado con sistemas REST

20. A5: CSRF
En qué consiste…
Este tipo de ataque se produce cuando una web permite realizar operaciones
sensibles a usuarios sin un rigor adecuado. A diferencia del XSS aquí quien
confía es la web en el usuario y no el usuario en la web.
La base del problema
• Los navegadores incluyen las credenciales en cada petición. ¿Qué ocurre si
en una web maligna se hace referencia a un contenido u operación de una
aplicación que admite CSRF?
• Así, TODAS las aplicaciones que dejan la autenticación/autorización
únicamente en el sistema de credenciales del contenedor(Cookies de sesión,
Basic-Auth, IP, Certificado X.509 de cliente, usuario de Dominio…) son
VULNERABLES.
Impacto
Aunque en general todas las aplicaciones son vulnerables, es dificil explotar
dicha vulnerabilidad porque implica un conocimiento profundo de la
aplicación atacada.

21. A5: CSRF
El atacante almacena en ataque en una web o bien manda un
1 correo
Aplicación vulnerable
Un tag ‘<img ..>’ a CSRF
contiene el ataque
Administration
Communicatio
Bus. Functions
Transactions
E-Commerce
n nowledge
Accounts
Finance
Mgmt
Mientras ve el portal del atacante, la victima
2
K
se loguea sin saberlo en la aplicación
Custom Code
3
La aplicación cree que
El tag ‘<img’ cargado es una solicitud de un
por el browser de la usuario legítimo y
victima le lleva a la realiza la operación
aplicación y usa sus
credenciales
precargadas

22. A5: CSRF
Cómo evitarse
1. Enviar/Usar un token único que se debe enviar/recibir en
operaciones sensibles.
2. Realizar una segunda autenticación para determinadas
operaciones.
3. Sistemas CAPTCHA
Qué NO VALE
1. Sólo admitir peticiones por POST
2. Reescritura de URLs
Más info
www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet

23. A6: Configuraciones de Seguridad
En qué consiste…
Si se usa una determinada API o plataforma de seguridad, es importante que
se configure adecuadamente. Ejemplos de frameworks de seguridad: Spring
Security, HDIV, ESAPI, JASS, Jguard, etc. Incluso las propias.
También se engloban aquí las APIs criptográficas: BouncyCastle, JSSE, XML
Signature, etc….
La base del problema
• El código fuente no es un secreto.
• La configuración de la seguridad es distinta dependiendo del entorno.
• Desarrollo de ‘puertas traseras’ para pruebas que pasan a REAL
• Falta de actualización/control de las librerias de seguridad
• Presencia de cuentas por defecto, etc
Impacto
El atacante debe ser un poco friki(pero los hay). El atacante puede, al tener
acceso, incorporar scripts XSS, obtener datos de usuarios, cuentas, etc.

24. A6: Configuraciones de Seguridad
Knowledge Mgmt
Communication
Administration
Bus. Functions
E-Commerce
Transactions
Accounts
Finance
Database
Custom Code
App Configuration
Development
Framework
App Server
QA Servers
Web Server
Hardened OS
Atacante Test Servers
Source Control

25. A6: Configuraciones de Seguridad
Cómo evitarse
1. Más formación y conocimiento en los sistemas de seguridad
2. Revisiones de código: también la configuración de la
seguridad
3. Verificar periódicamente que no la API está libre de bugs de
seguridad
4. Tener una arquitectura de seguridad debidamente
documentada
Qué NO VALEperiódicos de AppScan
5. Escaneos
1. Dar por hecho que el framework lo hace todo
2. Dar por hecho que la configuración es adecuada
Más info
Ver cada API/Librería

26. A7: Restricción de acceso a URLs
En qué consiste…
¿Cómo se protege el acceso a determinadas URLs/páginas? Es importante
entender que aquí no se trata de proteger la aplicación como un todo, sino
que usuarios con un determinado nivel de acceso no accedan a páginas
administrativas .
The ‘schoolboy mistake’
• Mostrar sólo los menús o links a los que tiene acceso el usuario en cuestión
Impacto
Es relativamente fácil el realizar estos ataques. El atacante puede visualizar
información de otros usuarios o realizar acciones para las que no deberia
tener permiso.

27. A7: Restricción de acceso a URLs
Me doy cuenta que parte de
https://www.onlinebank.com/user/getAccounts
la URL es el rol
/user/getAccounts
Modifico la URL para ver si
funciona
/admin/getAccounts, or
/manager/getAccounts
Si funciona…soy
administrador

28. A7: Restricción de acceso a URLs
Cómo evitarse
1. Verificar la arquitectura de seguridad
2. Verificar que cada URL está protegida por un filtro (ya sea en
el web.xml o producto /API) o bien introducir chequeos en el
propio código(comprobación de roles y permisos) mediante
sistemas como Spring Security, ESAPI, etc.
3. Usar sistemas/frameworks que controlen esta funcionalidad
4. Hacer hacking ético (WebScarab por ejemplo) para
forzar/testar este tipo de intrusiones.
5. Escaneos periódicos
6. Toda aplicación debe cumplir:
a) Restringir acceso sólo a usuarios autenticados
b) Chequear el acceso en base al rol del usuario
c) Deshabilitar acceso a ficheros protegidos o de
configuración

29. A8: Redirects and forwards inválidos
En qué consiste…
Es relativamente común la práctica de redireccionar a otra página e incluso
incorporar parámetros en la URL. Si no se chequean esos parámetros, el
atacante podria reenviar al usuario a una página o portal malicioso.
El caso de los forwards es similar. Consisten en enviar la misma petición a otra
página(habitualmente de la misma aplicación). Si la página a realizarse el
forward es un parámetro o similar, se podría saltar el control de
autenticación o autorización.
The ‘schoolboy mistake’
• No validar los parámetros que pueden usarse al abrir una ventana o realizar
un forward. Importante…. NO VALE CON COMPROBAR EN EL CLIENTE.
• IMPORTANTE: ESTO NO ES PISHING
Impacto
Es complicado el llevar a cabo estos ataques porque no todas las aplicaciones
usan estos métodos.

30. A8: Redirects and forwards inválidos
1 El atacante envía el ataque via email o link
From: Tu Banco(o tu mujer)
Subject: Te ha tocado un premio
Enhorabuena, pincha aqui, 3 La aplicación redirige
inconsciente de la vida! a la víctima al portal
fraudulento
Knowledge Mgmt
Communication
Administration
Bus. Functions
Transactions
E-Commerce
Accounts
Finance
La victima pincha en el ink que le lleva a la
2 página del banco…(con un regalo)
Custom Code
LA petición viaja a la
aplicación vulnerable, que
usa el parámetro mal
formado para reenviar al
usuario a la url incorrecta Evil Site
4 El atacante instala software
http://www.irs.gov/taxrefund/claim.jsp?year= en el PC del usuario o le
2006&… &dest=www.evilsite.com solicita información

31. A8: Redirects and forwards inválidos
Cómo evitarse
1. Evitar usar redirects y forwards
2. Si se usan, no usar parámetros como parte de la URL
3. Si se deben usar, validar que cada parámetro es válido y está
autorizado para el usuario o bien ‘mapear’ la petición en el
servidor con la URL en cuestión.
4. Hacer hacking ético (WebScarab por ejemplo) para
forzar/testar este tipo de intrusiones.
5. Escaneos periódicos
6. ESAPI proporciona métodos seguros de redirects y forwards.
Ver: SecurityWrapperResponse.sendRedirect( URL )
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/filters/
SecurityWrapperResponse.html#sendRedirect(java.lang.String)

32. A9: Almacenamiento criptográfico inseguro
En qué consiste…
Esto ocurre en las siguientes situaciones:
1. No se identifica adecuadamente qué información se debe proteger.
2. No se conoce adecuadamente donde se almacena dicha información(BD,
ficheros, backups, etc)
3. No se encripta la información de forma adecuada(criptografía insegura,
claves criptográficas comprometidas, etc)
4. No se tiene una política de destrucción de los datos cifrados ni renovación
de las claves de cifrado
The ‘schoolboy mistake’
• Usar algoritmos de criptografía ‘debiles’. Ej: DES
• Almacenar las claves de cifrado de forma insegura o directamente en claro.
Impacto
Es dificil que se produzca esta situación.
Pérdida de credibilidad de toda la compañia.

33. A9: Almacenamiento criptográfico inseguro
La víctima introduce
1 su PAN para comprar
Bus. Functions
Administration
Communicatio
Transactions
E-Commerce
Knowledge
Accounts
Finance
Mgmt
n
Custom Code
El atacante recopila Log files
4
los logs y roba 4 La aplicación guarda en 2
millones de los logs el PAN pq lo
tarjetas necesita luego
Las trazas están 3
accesibles a todos los
operadores, uno de
ellos, becario, pasando
una mala racha

34. A9: Almacenamiento criptográfico inseguro
Como evitarlo
1. Verificar la Arquitectura:
a) Identificar qué se debe proteger.
b) Identificar dónde se almacena(BD, ficheros, backups, etc)
c) No se encripta la información de forma adecuada(criptografía
insegura, claves criptográficas comprometidas, etc)
d) No se tiene una política de destrucción de los datos cifrados ni
renovación de las claves de cifrado
2. Usar mecanismos de encriptación adecuados. Posibilidades:
a) Ficheros completos
b) Base de Datos
c) Elemento en cuestión
3. Usar los mecanismos correctamente:
a) Strong cryptography (Preferiblemente, un HSM)
b) Proteger las claves(generación, uso y destrucción)  HSM
c) Tener planificado un posible cambio de claves(incluso en caso de
urgencia)
4. Verificar la implementación(código, librerias, etc)

35. A10: Insuficiente protección de comunicaciones
En qué consiste…
Esto ocurre en las siguientes situaciones:
1. No se identifica adecuadamente qué información a enviar/recibir se debe
proteger(identificadores de clientes, tarjetas, etc)
2. No se conoce adecuadamente donde se envía dicha información(BD,
clientes, servicios web o procesos remotos internos)
3. No se utilizan métodos adecuados para proteger las comunicaciones
4. A veces, el problema es el cliente (proxy)
The ‘schoolboy mistake’
• Se encriptan con HTTPS la navegación, pero es posible también hacerlo por
HTTP o bien se envían las credenciales de usuario por email ordinario
Impacto
Es ciertamente dificil que se produzca este ataque(Man in the middle)
Pérdida de credibilidad de toda la compañia.

36. A10: Insuficiente protección de comunicaciones
Clientes
Victima
Custom Code Backend Systems
Empleados
1 2
Se capturan Se capturan
credenciales y credenciales y
datos datos que viajan
Desde el por la red
exterior.. Desde el interna
interior…

37. A10: Insuficiente protección de comunicaciones
Como evitarlo
1. Verificar la Arquitectura:
a) Identificar qué se debe proteger.
b) Identificar dónde se almacena(BD, ficheros, backups, etc)
c) No se encripta la información de forma adecuada(criptografía
insegura, claves criptográficas comprometidas, etc)
d) No se tiene una política de destrucción de los datos cifrados ni
renovación de las claves de cifrado
2. Usar mecanismos de encriptación adecuados. Posibilidades:
a) Ficheros completos
b) Base de Datos
c) Elemento en cuestión
3. Usar los mecanismos correctamente:
a) Strong cryptography (Preferiblemente, un HSM)
b) Proteger las claves(generación, uso y destrucción)  HSM
c) Tener planificado un posible cambio de claves(incluso en caso de
urgencia)
4. Verificar la implementación(código, librerias, etc)