Los 10 principales

riesgos en

aplicaciones web

(OWASP Top 10 2013)

Sergio Martínez Pacheco@superserch

Open Web Application Security Project

• Una comunidad libre y abierta enfocada en la seguridad de las aplicaciones

• OWASP Top Ten 2013– Lista de los 10 más importantes y comunes riesgos en

aplicaciones web

– Busca crear conciencia en el origen de los problemas de seguridad en las aplicaciones web

– La seguridad de las aplicaciones es responsabilidad de los desarrolladores

OWASP Top Ten Agradecimientos

Aspect Security

HP

Minded Security

Softtek

Trustwave, Spiderlabs

Veracode

WhiteHat Security Inc.

Sobre riesgos y no solo vulnerabilidades

OWASP Top Ten 2013 Edition

A1: Inyección

• Engañar a la aplicación al incluir instrucciones que no esperaba en los datos enviados a un interprete

• Interprete: Toma una cadena y la interpreta como instrucciones (SQL, LDAP, Shell, Xpath …)

• Muy común con un impacto severo (datos modificados, acceso a cuentas o incluso al SO)

A1: Ejemplo Inyección SQLC

apa

de

aplic

ació

nC

apa

de

Red

Fire

wal

l

Plataforma

Custom Code

Acc

ou

nts

Fin

ance

Ad

min

istr

atio

n

Tran

sact

ion

s

Co

mm

un

icat

ion

Kn

ow

led

ge

Mgm

tE-

Co

mm

erc

e

Bu

s. F

un

ctio

ns

Fire

wal

l

Base de Datos

Petición

HTTP

SQL

query

DB Table

Respuesta

HTTP

El atacante usa una forma para enviar como datos:‘ OR 1=1 --

La Aplicación reenvía el ataque a la base de datos:SELECT * FROM

accounts WHERE

acct=’’ OR 1=1—’

La Base de datos entrega la información a la aplicación

El Atacante obtiene los datos

A1: ¿Cuál fue el problema?

String query = "SELECT * FROM accounts WHERE custID='" +

request.getParameter("id") + "'";Statement st = conn.createStatement();ResultSet rs = st.executeQuery(query);

A1: ¿Cuál fue el problema?

String query = "SELECT * FROM accounts WHERE custID='" +

request.getParameter("id") + "'";PrepareStatement ps = conn.

prepareStatement(query);ResultSet rs = ps.executeQuery();

A1: ¿Cuál fue el problema?

String query = "SELECT * FROM accounts WHERE custID=?";

PrepareStatement ps = conn. prepareStatement(query);

ps.setString(1, request.getParameter("id") );

ResultSet rs = ps.executeQuery();

A1: Recomendaciones

• Evitar usar interpretes

• Usar interfaces que soporten variables ligadas

• Codificar toda entrada antes de pasarla a un interprete

• Validar todos los valores del usuario contra una lista de palabras aceptadas (white list)

• Minimizar los privilegios a la base de datos

A1: Más información

• Para mas detalles, se recomienda leer:

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

A2: Fallos de Autenticación y manejo de sessiones

• HTTP es un protocolo “stateless”

– Las credenciales deben viajar con cada petición

– Debería usar SSL para todo lo que requiera autenticación

• Se usa el SESSION ID para mantener el estado de la sesión

• Como Impacto se puede comprometer las cuentas de los usuarios o secuestrar las sesiones

A2: Fallos típicos

• El SESSION ID puede estar expuesto en la red, en los navegadores, logs, URLs, …

• El uso de puertas alternas (cambia mi contraseña, recordar mi contraseña, recuperar mi contraseña, pregunta secreta, salir, etc.)

A2: Recomendaciones

• Verificar la Arquitectura de la aplicación

– La autenticación debería ser simple, centralizada y estandarizada

– Utiliza el mecanismo de control de SESSION ID que provee el contenedor

– Usar SSL para proteger las credenciales y la sesión siempre

A2: Recomendaciones

• Verificar la Implementación de la aplicación

– Revisar el certificado SSL

– Examinar todas las funciones relacionadas a la autenticación

– Verificar que el “Salir” en verdad destruya la sesión

A2: Más Información

• Para mas detalles, se recomienda leer:

https://www.owasp.org/index.php/Authentication_Cheat_Sheet

A3: Cross-Site Scripting (XSS)

• Código de un atacante es enviado a un usuario– Guardado en bases de datos

– Reflejado vía una forma web (campos de forma, ocultos, URLs, etc)

– Enviado directamente al motor de JavaScript

• Impacto– Robo de información (Sesión, datos, redirigir al usuario a

páginas de phishing o malware)

– Instalar un XSS proxy que permite al atacante observar el comportamiento de los usuarios de un sitio web vulnerable

A3: Ejemplo

Sitio Web Vulnerable

1 El Atacante pone una trampa- Ejemplo en el perfil

2 La victima en la página entra Al perfil del atacante

Custom Code

Acc

ou

nts

Fin

ance

Ad

min

istr

atio

n

Tran

sact

ion

s

Co

mm

un

icat

ion

Kn

ow

led

ge M

gmt

E-C

om

mer

ce

Bu

s. F

un

ctio

ns

El atacante pone un script malicioso que se guardaen la base de datos de la aplicación

El script corre en el navegador de la victimacon acceso completo al DOM y a las cookies

3 Silenciosamente el script manda la sesión de la victima al atacante

A3: Recomendaciones

• Elimine el XSS– No incluir datos suministrados por el usuario en las

páginas generadas

• Defensa contra el XSS– Codifique todos los datos suministrados por el usuario

(OWASP ESAPI, Java Encoders)

– Validación de datos vía “white list”

– Para grandes volúmenes de HTML sanitizar los datos con OWASP AntiSamy para hacerlos seguros

A3: Contextos de ejecución del HTML

CSS Property Values(e.g., .pdiv a:hover {color: red; text-decoration:

underline} )

JavaScript Data(e.g., <script>

someFunction(‘DATO’)</script> )

HTML Attribute Values(e.g., <input name='persona' type='TEXT'

value=’Valor'> )

HTML Element Content(e.g., <div> Algún texto a desplegar </div> )

URI Attribute Values(e.g., <a href=" http://site.com?search=DATO" )

#4: Todos no-alfanumericos < 256 \HH

ESAPI: encodeForCSS()

#3: Todos no-alfanumericos < 256 \xHH

ESAPI: encodeForJavaScript()

#1: ( &, <, >, " ) &entity; ( ', / ) &#xHH;

ESAPI: encodeForHTML()

#2: Todos no-alfanumericos < 256 &#xHH;

ESAPI: encodeForHTMLAttribute()

#5: Todos no-alfanumericos < 256 %HH

ESAPI: encodeForURL()

Cualquier otro contexto NO DEBE incluir datos no confiables

A3: Más información

• Para mas detalles, se recomienda leer:

https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

A4: Referencias inseguras a objetos directos

• ¿Cómo proteges el acceso a tus datos?– Tiene que ver con A2 y A7

• Errores comunes– Sólo listo los objetos autorizados al usuario actual

– Escondo las referencias a objetos en campos ocultos

– … pero no validó estas restricciones en el servidor

• Impacto: Usuarios pueden acceder a archivos o datos no autorizados

A4: Ejemplo

• El atacante observa que el parámetro cuenta es A113 - ?cuenta=A113

• Lo modifica con un número cercano -?cuenta=A114

• El atacante tiene acceso a la información de la cuenta de la victima

https://www.bancoenlinea.com/misCuentas?cuenta=A113

A4: Recomendaciones

• Eliminar las referencias directas a objetos

– Reemplazar las referencias con valores temporales

• Validar la referencia al objeto

– Verificar el formato del parámetro

– Verificar si el usuario tiene acceso al objeto solicitado

http://app?file=Report123.xlshttp://app?file=1

http://app?id=MAXP801204http://app?id=4r556g3

A5: Mala configuración de la seguridad

• Las aplicaciones web dependen de una plataforma segura– Todo desde el SO al servidor de aplicaciones

• ¿Es tu código fuente un secreto?– La seguridad no debe requerir la secrecía del código

• La administración de la configuración debe abarcar todas las partes de la aplicación– Las contraseñas deben cambiarse en producción

• Impacto: acceso por cuentas por defecto o mala configuración de los servicios

A5: Recomendaciones

• Verifique la administración de la configuración– Guía de “hardening” de la aplicación

• La automatización es de mucha ayuda aquí

– Debe abarcar toda la plataforma y la aplicación

– Analizar los efectos en la seguridad que generan los cambios

• ¿Puedes tener un “dump” de la configuración de la aplicación?– Si no puedes verificarlo no es seguro

– Los scanners encuentran problemas genéricos de configuración y falta de parches

A6: Exposición de datos sensibles

• Almacenando y transfiriendo datos sensibles de manera insegura– Falla de identificar datos sensibles

– Falla de identificar los lugares donde estos datos se guardan

– Falla de identificar los lugares en donde estos datos son enviados

– Falla de proteger estos datos apropiadamente en todo lugar

A6: Impacto

• Acceso o modificación por parte delos atacantes a información privada o confidencial

• Los atacantes obtienen secretos que pueden utilizar en otros ataques

• Afecta la reputación del sitio / aplicación• Costo de recuperación del incidente

– Análisis forense, envío de disculpas, reexpedición de tarjetas, seguros contra robo de identidad

• Demandas

A6: Ejemplo

Custom Code

Acc

ou

nts

Fin

ance

Ad

min

istr

atio

n

Tran

sact

ion

s

Co

mm

un

icat

ion

Kn

ow

led

ge

Mgm

tE-

Co

mm

erce

Bu

s. F

un

ctio

ns

Log files

1 La victima da su tarjeta de crédito para realizar una reservación

2 Por un error en la comunicación con el gateway de pagos, el sistema logguea el error junto con la tarjeta

3 Los logs están disponibles a los miembros del equipo de desarrollo para debugueo

4 Un empleado malicioso roba los números de tarjetas de crédito

A6: Recomendaciones

• Identificar claramente los datos sensibles y los lugares en donde se almacenan o transportan

• Usa mecanismos adecuados de protección (cifrado de archivos, bases de datos, datos)

• Usa mecanismos estándar cuidando el proceso de generación, distribución y almacenamiento de llaves

• El sistema debe estar preparado para cambiar las llaves

A6: Verificar la implementación

• ¿Se usan algoritmos fuertes y estándar?

• ¿Las llaves, certificados y contraseñas están guardados y protegidos adecuadamente?

• ¿Existe un mecanismo seguro para distribuir y un plan para el cambio de llaves?

A6: Capa de transporte

• Usar siempre TLS en todas las comunicaciones con datos sensibles

• Cifrar los mensajes de manera individual antes de la transmisión

• Firmar los mensajes antes de la transmisión

• Verificar los certificados SSL antes de usarlos

A6: Más Información

• Para mas detalles se recomienda leer:

https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet

A7: Falta de controles de acceso por función

• ¿Cómo proteger el acceso a las URLs (Páginas) o funciones referenciadas por un URL y parámetros?

– Relacionado con A2 y A4

• Impacto

– Poder invocar funciones y servicios para los que no se está autorizado

– Acceder a la información de otros usuarios

– Realizar acciones privilegiadas

A7: Ejemplo

• El atacante observa que el el URL esta su rol “usuario”

• Lo modifica probando otros roles/admin/obtenerCuentas/manager/obtenerCuentas

• Obtiene acceso a información privilegiada

https://www.bancoenlinea.com/usuario/obtenerCuentas

A7: Recomendaciones

• Para cada función un sitio debe:

– Restringir el acceso para sólo usuarios autenticados (si no es público)

– Asegurarse de cumplir los permisos basados en usuarios o roles (Si es privado)

– Bloquear por completo las peticiones a paginas no autorizadas (archivos de configuración, archivos de logs, código fuente, etc)

A7: Verificaciones

• Verificar que cada URL (y cada uno de sus parámetros) que hacen referencia a una función estén protegidos por:– Un filtro externo (como el web.xml de Java EE)– Validaciones internas en TU código

• Verificar que el servidor no entregue tipos de archivo no autorizados

• Usar Zed Attack Proxy (ZAP) de OWASP o un navegador para falsificar solicitudes no autorizadas

A7: Más información

• Para detalles sobre Zed Attack Proxy (ZAP)

https://code.google.com/p/zaproxy/wiki/Introduction

A8: Cross Site Request Forgery (CSRF)

• Consiste en engañar al navegador de la victima para que realice una petición a una aplicación vulnerable

• La vulnerabilidad es causada por que los navegadores automáticamente envían información de autenticación en cada petición (SESSION ID, IP Address, Windows DomainCredentials, …)

A8: Imagina …

• ¿Y que tal si un Hacker pudiera mover tu puntero de ratón y dar click en algunas ligas en ti aplicación bancaria?

• ¿Qué podrían hacerte hacer?

A8: Ejemplo

Custom Code

Acc

ou

nts

Fin

ance

Ad

min

istr

atio

n

Tran

sact

ion

s

Co

mm

un

icat

ion

Kn

ow

led

ge

Mgm

tE-

Co

mm

erce

Bu

s. F

un

ctio

ns

El atacante coloca un tag <img> oculto que contieneel ataque al sitiovulnerable

1 El atacante prepara una trampa en un sitio en internet(o por un correo electrónico)

2 Mientras está firmado en el sitio vulnerable, la victima ve el sitio del atacante

Al cargar el tag <img> el navegador envía un SET (Incluyendo credenciales) a la aplicación vulnerable

Aplicación con vulnerabilidad CSRF

3 El sitio vulnerable ve una petición legitima de la victima y realiza la operación que se solicitó

<imgsrc=”https://www.bancoenlinea/usuario/transfiere?ctaDestino=A113

&cantidad=1000" />

A8: Recomendaciones

• Agregar un “secreto” (token) que no se envíe automáticamente a todas las peticiones sensibles

• Los Tokens deben ser criptográficamente fuertes o completamente aleatorios

• No permitas que los atacantes coloquen ataques en tus sitios– Codifica adecuadamente todo dato que recibas de

los usuarios

A8: Recomendaciones

• Guardar un Token en la sesión y agregarlo a todas las formas y ligas

– <input name="token" value="33775a43db221” type="hidden">

– URL de un solo uso: /cuentas/33775a43db221

– Como parámetro: /cuentas?auth=33775a43db221

• Usar un único token por función

• Usar una doble autenticación para funciones sensibles

A8: Más información

• para más detalles se recomienda leer:

https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet

A9: Usar componentes con vulnerabilidades conocidas

https://www.aspectsecurity.com/news/the-unfortunate-reality-of-insecure-libraries/

A9: Ejemplo

A9: Recomendaciones

• Ideal– Periódicamente y de manera automática realizar

verificaciones de componentes usados

• Mínimo– A mano revisar periódicamente si los componentes

están actualizados

– Revisar cuales componentes cuentan con vulnerabilidades reportadas• CVE y otros repositorios de vulnerabilidades

A9: Más información

• En el mundo Java:

https://www.owasp.org/index.php/OWASP_Dependency_Check

• En .Nethttps://github.com/OWASP/SafeNuGet

A10: Redirecciones sin validación

• Las redirecciones son comunes y usualmente contienen datos generados por el usuario, si no están validados un atacante puede enviar a un usuario al sitio de su preferencia

• Los Forwards o include envían la petición a una nueva página en la aplicación actual.

• Algunas veces los parámetros definen la página destino

• Si no están validados un atacante podría pasar los controles de autorización o autenticación

A10: Impacto

• Enviar a una victima a un sitio de phishing o malware

• Un atacante podría saltase los niveles de seguridad dentro de la aplicación

A10: Ejemplo

Custom Code

Acc

ou

nts

Fin

ance

Ad

min

istr

atio

n

Tran

sact

ion

s

Co

mm

un

icat

ion

Kn

ow

led

ge

Mgm

tE-

Co

mm

erce

Bu

s. F

un

ctio

ns

La petición se envia al sitiovulnerable, incluyendo el ataque

From: Servicio de Administración Tributaria

Subject: Devolución de Impuestos

Nuestros registros indican que necesitaaclarar los datos presentados en sudeclaración, en la siguiente liga

Sitio falso

1 El atacante envía un ataque en un correo o una página a su victima

2 La victima da click al link con el parámetro sin validación

3 La aplicación redirecciona la victima al sitio del atacante

4 El sitio del atacante instala malware o pide información confidencial

A10: Recomendaciones

• Evitar usar redirecciones y forwards tanto como sea posible

• Si no, no usar parámetros para definir el URL destino

• Si debe usar parámetros entonces:– Validar cada parámetro para asegurarse que es

válido y autorizado

– Usar mapeos del lado del servidor para transformar la opción provista por el usuario a una página destino real

Resumen

• Desarrolle código seguro– Siga las mejores prácticas (Guía para construir aplicaciones

web seguras)https://www.owasp.org/index.php/Guide

– Use los OWASP cheat sheetshttps://www.owasp.org/index.php/Cheat_Sheets

• Revise su aplicación– Guía para revisiones de código

https://www.owasp.org/index.php/Code_Review_Guide– Guía de pruebas

https://www.owasp.org/index.php/Testing_Guide

Te Recomendamos:¿Dónde? ¿Cuándo? ¿Quién? ¿Qué?

Principal 26 Junio 17:00 Hrs

FI-WARE / INFOTEC

Presentación de la región México de FI-Lab

Principal 25 Junio 21:00 Hrs

Hugo Estrada Ambientes Inteligentes

Pitágoras 26 Junio 11:00 Hrs

Javier Solís Web Semántica de la teoría a la práctica

Arquímedes 26 Junio 21:00 Hrs

FI-WARE FI-WARE

Arquímedes 27 Junio 15:00 Hrs

Jorge Jiménez SWB Social, Maximiza tecnológicamente el potencial de los medios sociales

Arquímedes 28 Junio 10:00 Hrs

Iván Lozada y Valentín Gómez

Equipos de trabajo auto dirigidos enfocados a la calidad de software basados en la disciplina TSP/PSP

Arquímedes 26 Junio 22:00 y 23:00 hrs

Eduardo Zepeda y Héctor Cuevas

Hackeando al sexo femenino y SexTeen, Cuando las personas y la tecnología te traicionan

Síguenos en nuestras redes sociales: