PDF de programación - Los diez riesgos más importantes en aplicaciones web

OWASP Top 10 – 2010
Los diez riesgos más importantes en
aplicaciones web

Fabio Cerullo
Comité Global de Educación
OWASP
[email protected]

Copyright © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.

The OWASP Foundation
http://www.owasp.org/

¿Quién soy?

Ingeniero en Informática de la Universidad Católica Argentina.

-  Especialista en Seguridad de la Información en Allied Irish Banks.
- 
-  Certified Information Security Systems Professional (CISSP)
-  Miembro del Comité Global de Educación OWASP.
-  Presidente del Capitulo Irlandés de OWASP.

Misión del Comité Global de Educación OWASP: Proporcionar

sensibilización, capacitación y servicios educativos a las empresas,
instituciones gubernamentales y educativas sobre seguridad en
aplicaciones.

OWASP - 2010

Introducción al Top 10

-  Es un documento EDUCATIVO.
-  Es GRATUITO.
-  DESCRIBE los riesgos más críticos en aplicaciones Web
-  Versión 2010 próximamente en español

Para cada riesgo, aporta:

- Descripción del mismo
- Escenario de ejemplo de un ataque
- Pautas para verificar si nuestra aplicación es vulnerable
- Recomendaciones para prevenir dicho riesgo

OWASP - 2010

¿Que ha cambiado en esta versión?

Se centra en los Riesgos, no solo en Vulnerabilidades

Su nuevo titulo es: “Los diez riesgos más importantes en aplicaciones web 2010”

Ranking de Riesgos en OWASP Top 10

Se basa en la metodologia de catalogacion de riesgos OWASP, utilizada para priorizar el Top 10

Riesgos agregados y eliminados

•  Agregado: A6 – Configuración Defectuosa de Seguridad

•  Se encontraba en el Top 10 2004: Gestión Insegura de la Configuración
•  Falla relativamente común y MUY peligrosa que no es bien conocida

•  Agregado: A10 – Redirecciones y Destinos no Validados
•  Eliminado: A3 – Ejecución de Ficheros Malintencionados

•  Principalmente una falla en PHP que esta perdiendo relevancia

•  Eliminado: A6 – Revelación de Información y Gestión Incorrecta de Errores

•  Falla muy prevalente, que no introduce demasiado riesgo (normalmente)

OWASP - 2010

Comparación del Top 10 2010 con 2007

OWASP Top 10 – 2007 (Anterior)

OWASP Top 10 – 2010 (Nuevo)

A2 – Fallas de Inyección

A1 – Inyección

A1 – Secuencia de Comandos en Sitios Cruzados (XSS)

A2 – Secuencia de Comandos en Sitios Cruzados (XSS)

A7 – Perdida de Autenticación y Gestión de Sesiones

A3 – Perdida de Autenticación y Gestión de Sesiones

A4 – Referencia Directa Insegura a Objetos

A5 – Falsificación de Petición en Sitios Cruzados (CSRF)

<era T10 2004 A10 – Gestión Insegura de la
Configuración>

=
=
+

A4 – Referencia Directa Insegura a Objetos

A5 – Falsificación de Petición en Sitios Cruzados (CSRF)

A6 – Configuración Defectuosa de Seguridad (NUEVO)

A8 – Almacenamiento Criptográfico Inseguro

A7 – Almacenamiento Criptográfico Inseguro

A10 – Falla de restricción de acceso a URL

A8 – Falla de restricción de acceso a URL

A9 – Comunicaciones Inseguras

<no disponible en T10 2007>

A3 – Ejecución de Ficheros Malintencionados

A6 – Revelación de Información y Gestión Incorrecta de
Errores

=
+
-
-

<eliminado del T10 2010>

<eliminado del T10 2010>

A9 – Protección Insuficiente en la Capa de Transporte

A10 – Redirecciones y Destinos No Validados (NUEVO)

OWASP - 2010

Metodología de Catalogación de Riesgo OWASP

Agente de
Amenaza

?

Vector de Ataque
1
2
3

Mediano

Facil

Dificil

1

Ejemplo de Inyección

Prevalencia de

Debilidad

Detectabilidad de

Debilidad

Impacto Tecnico

Impacto al

Negocio

Amplia

Comun

Poco Comun

2

1.66

Facil

Mediano

Dificil

2

*

Severo

Moderado

Menor

1

1

?

1.66 calificación de riesgo ponderado

OWASP - 2010

OWASP Top Ten (Edición 2010)

http://www.owasp.org/index.php/Top_10

OWASP - 2010

A1 – Inyección

Inyección significa…
• Incluir comandos mal intencionados en los datos de una aplicación los cuales
son enviados a un interprete

Los interpretes…
• Toman estos datos y los interpretan como comandos validos
• SQL, OS Shell, LDAP, XPath, Hibernate, etc…

La Inyección SQL es aun bastante frecuente
• Muchas aplicaciones todavía son susceptibles (no tendría que ser así)
• Por lo general es muy fácil de evitar

Impacto Típico
• Por lo general severo. Todos los contenidos de una base de datos pueden
potencialmente ser leídos o modificados.
• También puede permitir el completo acceso al esquema de la base de datos, o
cuentas de usuario, o incluso a nivel del sistema operativo

OWASP - 2010

Inyección SQL – Demostración



n
ó
i
c
a
c
i
l
p
A

e
d

a
p
a
C



d
e
R

e
d

a
p
a
C


s
t
n
u
o
c
c
A

Pedido
HTTP
APPLICATION

ATTACK


t

m
g
M



n
o
i
t
a
c
i
n
u
m
m
o
C


e
c
n
a
n
i
F



n
o
i
t
a
r
t
s
i
n
i
m
d
A


s
n
o
i
t
c
a
s
n
a
r
T


e
g
d
e
l
w
o
n
K

Respuesta
HTTP 

Consulta
SQL



e
c
r
e
m
m
o
C
-
E


s
n
o
i
t
c
n
u
F


.
s
u
B

Custom Code

App Server

Web Server

Hardened OS


l
l
a
w
e
r
i

F


l
l
a
w
e
r
i

F


s
e
s
a
b
a
t
a
D


s

m
e
t
s
y
S
y
c
a
g
e
L



Tabla BD



s
c
r
s
e
R
n
a
m
u
H


s
e
c
i
v
r
e
S
b
e
W



s
e
i
r
o
t
c
e
r
i

D






g
n
i
l
l
i

B

"SELECT * FROM
Account Summary
accounts WHERE
Account:
Account:
acct=‘’ OR
SKU:
SKU:

1=1--’"

Acct:5424-6066-2134-4334
Acct:4128-7574-3921-0192
Acct:5424-9383-2039-4029
Acct:4128-0004-1234-0293
1. Aplicación presenta un
formulario web al atacante
2. Atacante envía un ataque en los
datos del formulario
3. Aplicación dirige el ataque a la
base de datos en una consulta SQL
4. Base de datos ejecuta el ataque y
envía los resultados cifrados
nuevamente a la aplicación
5. Aplicación descifra los datos
normalmente y envía los resultados
al atacante

OWASP - 2010

A1 – Como evitar Fallas de Inyección
 Recomendaciones

1.  Evitar el interprete completamente
2.  Utilizar una interfase que soporte variables parametrizadas (Ej.,

declaraciones preparadas, o procedimientos almacenados),
  Las variables parametrizadas permiten al interprete distinguir entre

código y datos

3.  Decodificar y convertir todas las entradas del usuario a su forma

mas simple antes de enviarlas al interprete

  Siempre efectuar una validación ‘positiva’ de todas las entradas

realizadas por el usuario

  Seguir el principio de mínimo privilegio en las conexiones con

bases de datos para reducir el impacto de una falla

 Referencias

  Para mayor información:

http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

OWASP - 2010

A2 – Secuencia de Comandos en Sitios Cruzados (XSS)

Ocurre cada vez que…
• Datos no validados de un atacante son enviados al navegador de una victima

Los datos no validados pueden…
• Encontrarse ALMACENADOS en una base de datos
• Ser REFLEJADOS desde una entrada web (formulario, campo oculto, URL, etc…)
• Ser enviados directamente a un cliente JavaScript

Virtualmente todas las aplicaciones web tienen este problema
• Intentar esto en un navegador – javascript:alert(document.cookie)

Impacto Típico
• Robar la sesión del usuario, robar datos sensibles, redireccionar un usuario hacia
un sitio de malware o phishing
• Mas grave: Instalar un proxy XSS que permite a un atacante observar y dirigir
todas las actividades de un usuario en el sitio vulnerable y forzarlo hacia otros
sitios

OWASP - 2010

XSS - Demostración

1

Atacante establece una trampa – actualizar perfil

Atacante ingresa un
script malicioso en una
pagina web que almacena
los datos en el servidor

2

Victima visualiza la pagina – accede al perfil

Script se ejecuta en el
navegador de la victima

Aplicación con
vulnerabilidad XSS
Reflejado


t

m
g
M


e
g
d
e
l
w
o
n
K



n
o
i
t
a
c
i
n
u
m
m
o
C


s
n
o
i
t
c
n
u
F


.
s
u
B


e
c
r
e
m
m
o
C
-
E



n
o
i
t
a
r
t
s
i
n
i
m
d
A


s
n
o
i
t
c
a
s
n
a
r
T


s
t
n
u
o
c
c
A


e
c
n
a
n
i

F

Custom Code

3

Script silenciosamente envía la sesión de la victima al atacante

OWASP - 2010

XSS - Demostración

BEEF Demo

OWASP - 2010

A2 – Como evitar Fallas de XSS

 Recomendaciones

  Eliminar la Falla

salida

  Defenderse de la Falla

  No incluir entradas suministradas por el usuario en la pagina de

  Recomendación Principal: Codificar todos los datos de entrada en la

pagina de salida (Utilizar OWASP’s ESAPI para dicha tarea):


http://www.owasp.org/index.php/ESAPI

  Siempre efectuar una validación ‘positiva’ de todas las entradas

realizadas por el usuario

  Cuando grandes cantidades de HTML son suministradas por el
usuario, utilizar OWASP’s AntiSamy para sanitizar dicho HTML
Ver: http://www.owasp.org/index.php/AntiSamy

 Referencias

  Para ver como codificar datos en la pagina de salida:

http://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet
OWASP - 2010

(AntiSamy)

A3 – Perdida de Autenticación y Gestión de
Sesiones

HTTP es un protocolo “sin estado”
•  Significa que las credenciales tienen que viajar en cada pedido HTTP
•  Debería utilizar SSL para todo contenido que requiere autenticación

Fallas en la gestión de sesiones
•  SESSION ID es utilizado para mantener el estado ya que HTTP no puede

•  Para un atacante es igual de útil que poseer el usuario y contraseña

•  SESSION ID es típicamente expuesto en la red, en el navegador, los logs,

etc

Tener cuidado con las “puertas laterales”
•  Cambio de contraseña, recordar contraseña, olvidar la contraseña, pregunta

secreta, desconexión del sitio, cambio de correo electrónico, etc.

Impacto Típico
•  Cuentas de usuario comprometidas o sesiones de usuario secuestradas

OWASP - 2010

Perdida de Autenticación - Demostración

1

Usuario envia credenciales

www.boi.com?JSESSIONID=9FA1DB9EA...

Sitio utiliza reescritura de
URLs
(e