(In)Seguridad en la Web

OWASP Top-10 2013

Open Web Application Security Project Organización sin fines de lucro enfocada en mejorar la seguridad en el desarrollo de softwareMateriales y recursos bajo licencia  open source y gratuitosCientos de proyectos relacionados para análisis y verificación de seguridad en el software

∗OWASP Zed Attack Proxy

∗OWASP Web Testing Environment Project

∗OWASP ModSecurity Core Rule Set Project

∗OWASP CSRFGuard Project

∗OWASP Enterprise Application Security Project

www.owasp.org

¿Qué es OWASP?

OWASP Top Ten (2013 Edition)Los 10 riesgos de seguridad más críticos en

aplicaciones Web

A2: Quiebre de autenticación y administración

de la sesión

A3: Cross-Site Scripting (XSS)

A4: Referencia directa a objeto

inseguro

A5: Mala configuración de

Seguridad

A6: Exposición de datos sensibles

A7: Inexistente control de acceso a nivel de función

A8: Falsificación de Solicitud de sitio cruzado

(CSRF)

A9: Usar componentes vulnerables

A10: Reenvíos y redirecciones no

validadas

A1: Inyección

A1 - Inyección

• Engañar a una aplicación incluyendo comandos en los datos enviados a un intérprete.

Inyección significa…

• Toman strings y los interpretan como comandos• SQL, OS Shell, LDAP, XPath, Hibernate, etc…

Intérpretes…

• Muchas aplicaciones se mantienen susceptibles.• Aún cuando no es muy difícil evitarla.

SQL injection es bastante común

• Usualmente severo. La base de datos completa puede ser vista o modificada.• Incluso puede permitir acceso al esquema completo de la base de datos,

acceso a cuentas o acceso a nivel de sistema operativo.

Impacto típico

Ilustración de Inyección de SQL

Fire

wal

l

Hardened OS

Web Server

App Server

Fire

wal

l

Dat

abas

es

Lega

cy S

yste

ms

Web

Ser

vice

s

Dire

ctor

ies

Hum

an R

esrc

s

Billi

ng

Custom Code

APPLICATIONATTACK

Net

wor

k La

yer

Appl

icati

on L

ayer

Acco

unts

Fina

nce

Adm

inist

ratio

nTr

ansa

ction

s

Com

mun

icati

onKn

owle

dge

Mgm

tE-

Com

mer

ceBu

s. F

uncti

onsHTTP

request•SQL

query•DB Table

✇

HTTP response

✇

"SELECT * FROM accounts WHERE acct=‘’ OR 1=1--’"

1. La aplicación presenta un formulario al atacante.

2. El atacante escribe datos en el formulario

3. La aplicación envía el ataque a la base de datos en una query SQL.

4. La base de datos ejecuta la consulta que contiene el ataque y envía el resultado a la aplicación.

5. La aplicación prepara los datos de manera normal y los envía al atacante.

Account Summary

Acct:5424-6066-2134-4334Acct:4128-7574-3921-0192Acct:5424-9383-2039-4029Acct:4128-0004-1234-0293

Account:

SKU:

Account:

SKU:

Impedir fallas de inyección

• Evitar el intérprete completamente• Usar una interfaz que soporte variables de binding (por ejemplo sentencias

preparadas o procedimientos almacenados)• Las variables de binding permiten al intérprete distinguir entre código y datos.

• Codificar todas las entradas de usuario antes de entregárselas al intérprete.• Siempre efectuar validación de los datos de usuario, respecto de lo autorizado a

ingresar.• Siempre minimizar privilegios de base de datos para reducir el impacto de los

errores de seguridad.

Recomendaciones

• Para mayores detalles https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

Referencias

A2- Quiebre de la autenticación y administración de sesión

• Significa que las credenciales deben entregarse en cada request.• Debiera usar SSL para cada requerimiento de autenticación.

HTTP es un protocolo sin estado

• Se usa SESSION ID para controlar el estado dado que HTTP no puede.• Y es tan bueno como entregar las credenciales a un atacante.

• SESSION ID normalmente es expuesta en la red, en el browser, en los logs.

Fallas de manejo de sesión

• Cambiar la password, recordarla, olvido de contraseña, pregunta secreta, dirección de correo electrónico.

Cuidado con las puertas laterales

• Cuentas de usuario comprometidas o sesiones secuestradas

Impacto típico

Ilustración de quiebre de autenticación

Custom Code

Acco

unts

Fina

nce

Adm

inis

trati

onTr

ansa

ction

s

Com

mun

icati

onKn

owle

dge

Mgm

tE-

Com

mer

ceBu

s. F

uncti

ons1 El usuario envía credenciales

2

3 El usuario hace clic al link http://www.hacker.com en un foro.

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

4

El hacker observa los registros en www.hacker.com

Y encuentra el JSESSIONID del usuario.5 El hacker usa el JSESSIONID y

toma el control de la cuenta de la víctima.

El sitio usa reescritura de URL(Por ej. Escribe el ID de la sesión en la URL)

Evitar el Quiebre de la autenticación y administración de sesión.

• La autenticación debe ser simple, centralizada y estandarizada.• Usar el session ID provisto por su contenedor.• Asegurarse que SSL protege las credenciales y el session ID en todo

momento.

Verifique su arquitectura

• Veridicar su certificado digital• Examinar todas las funciones relacionadas con la autenticación• Verificar que el logoff realmente destruye la sesión• Use WebScarab o ZAP de OWASP para probar la implementación

Verificar la implementación

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

Siga las indicaciones desde:

A3 – Cross-Site Scripting (XSS)

• Los datos maliciosos de un atacante se envían al browser de un usuario inocente.

Ocurre en cualquier momento

• Almacenados en la base de datos• Reflejados desde la entrada (campo de formulario, campo oculto, Url)• Enviados directamente vía JavaScript

Datos maliciosos…

• Intente en su browser dogitando: javascript:alert(document.cookie)

Virtualmente toda aplicación web tiene este problema

• Robo de la sesión de usuario, robo de datos sensibles, reescritura de la página web, redirección del usuario a un sitio maligno.

• Instalar proxies XSS que permiten al atacante observar y dirigir todo el comportamiento de un usuario en un sitio vulnerable y forzar que el usuario acceda a otros sitios.

Impacto típico

Ilustración de XSS

Aplicación con vulnerabilidad XSS almacenada

3

2

El atacante pone la trampa: “Actualizar mi perfil” trap – update my profile

EL atacante ingresa un script malicioso en una página web que almacena datos en el servidor

1

La víctima visita la página e ingresa la información.

El script silenciosamente envía al atacante las cookies de sesión de la víctima

El script se ejecuta en el browser de la víctima con total acceso a la información que éste maneja

Custom Code

Acco

unts

Fina

nce

Adm

inist

ratio

nTr

ansa

ction

sCo

mm

unic

ation

Know

ledg

e M

gmt

E-Co

mm

erce

Bus.

Fun

ction

s

• Recomendaciones– Eliminar la falla

• No incluír datos entregados por el usuario en la página de salida– Defenderse contra la falla

• Usar políticas de seguridad de contenido• Recomendación primaria: Codificar la salida de toda la información ingresada

por el usuario.(Usar OWASP ESAPI o codificadores Java para codificar la salida)https://www.owasp.org/index.php/ESAPIhttps://www.owasp.org/index.php/OWASP_Java_Encoder_Project

• Crear una lista blanca de validación en todas las entradas que sean incluídas en la página

• Para grandes cantidades de código HTML entregado por el usuario, utilizar AntiSamy de OWASP para sanitizar ese HTML y hacerlo seguro. https://www.owasp.org/index.php/AntiSamy

• Referencias– Para cómo codificar código de salida apropiadamente, leer:

https://www.owasp.org/index.php/XSS_(Cross Site Scripting) Prevention Cheat Sheet

Impedir fallas XSS

A4 – Referencia directa a objeto

• Exigir autorización apropiada (falla al restringir acceso a URL)

¿Cómo proteger el acceso a los datos?

• Sólo listar los objetos autorizados para el usuario• Esconder las referencias a objetos en campos ocultos• No implementar esas restricciones en el lado del servidor• El atacante se “salta” ese control de acceso de capa de

presentación ingresando parámetros en la URL

Error común…

• Los usuarios pueden acceder a archivos o datos no autorizados.

Impacto típico

• El atacante se percata que el parámetro de su cuenta es 6065

?acct=6065

• Lo modifica a un número cercano: ?acct=6066

• Ahora el atacante tiene acceso a la información de la cuenta de la víctima.

Ilustración de Referencia directa a objeto

https://www.onlinebank.com/user?acct=6065

• Eliminar la referencia directa a un objeto– Reemplácelas con un valor de asignación temporal (ej. 1, 2, 3)– OWASP ESAPI entrega soporte para asignaciones numéricas y aleatorias

• Validar la referencia directa a un objeto– Verifique el valor del parámetro está correctamente formateado– Verifique que el usuario tiene acceso al objeto

• Restricciones de SQL query (constraints)– Verifique que el modo de acceso está permitido sobre el objeto

(lectura, escritura, eliminación)

Evitar la referencia directa a objeto

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

http://app?id=7d3J93Acct:9182374http://app?id=9182374

http://app?file=Report123.xlsAccess

ReferenceMap

A5 – Fallas en la Configuración de Seguridad

• Desde el SO hasta el servidor de aplicaciones

Las aplicaciones Web descansan en la seguridad

• Piense en todos los lugares a los que su código fuente viaja• La seguridad no debiera requerir código fuente secreto

¿Su código fuente es secreto?

• Todas las credenciales deben cambiarse en producción

La administración de credenciales debiera extenderse a todas las partes de la aplicación

• Instalación de backdoor aprovechando vulnerabilidades no parchadas en el servidor

• Acceso no autorizado a cuentas por defecto, funcionalidad de aplicaciones o datos

Impacto típico

Hardened OS

Web Server

App Server

Framework

Ilustración de Fallas en la Configuración de Seguridad

App Configuration

Custom Code

Acco

unts

Fina

nce

Adm

inist

ratio

nTr

ansa

ction

s

Com

mun

icati

onKn

owle

dge

Mgm

tE-

Com

mer

ceBu

s. F

uncti

ons

Test Servers

QA Servers

Source Control

Development

Database

Insider

• Verifique la administración de la configuración– Seguir guías de endurecimiento de la configuración– Debe cubrir la plataforma y la aplicación – Analizar efectos que produce en la seguridad

• Verificar la implementación– Buscar configuraciones genéricas y problemas de parches no instalados

Evitar Fallas en la Configuración de Seguridad

A6 – Exposición de datos sensibles

• Fallas al identificar datos sensibles• Fallas al identificar todos los lugares en los que se almacenan los datos sensibles

• Bases de datos, archivos, directories, logs, respaldos• Fallas al identificar los lugares a los que se envían los datos senibles

• A la web, a otras bases de datos, a socios de negocios, comunicaciones internas• Fallas al proteger apropiadamente estos datos en cada ubicación

Almacenar y trasnmitir datos sin seguridad

• Los atacantes acceden o modifican información confidencial o privada• Tarjetas de crédito, fichas personales, datos financieros

• Los atacantes extraen secretos para usar en ataques adicionales.• Pérdida de confianza en la compañia, insatisfacción del consumidor• Gastos en corregir el inicdente, gastos en seguros• El negocio es multado

Impacto típico

Ilustración de almacenamiento de datos inseguro

Custom Code

Acco

unts

Fina

nce

Adm

inis

trati

onTr

ansa

ction

sCo

mm

unic

ation

Know

ledg

e M

gmt

E-Co

mm

erce

Bus.

Fun

ction

s

1

24 Un atacante interno

roba 4 millones de números de tarjetas de crédito

Log files

3Los logs son accesibles a todos los miembros de IT

para debug

La víctima ingresa su número de tarjeta de crédito en un formulario

El manejador de errors registra los números de tarjetas de crédito en el

log, porque no hay comunicación con el

Sistema

• Verifique su arquitectura– Identifique todos los datos sensibles– Identifique todos los lugares donde se almacenan los datos– Use encriptación para contrarrestar las amenazas

• Protegerse con mecanismos apropiados– Encriptación de datos, encriptación de la base de datos, encriptación de los elementos

de datos

• Usar los mecanismos correctamente– Usar algoritmos robustos– Generar, distribuir y proteger claves apropiadamente– Estar preparados para cambio de claves

• Verificar la implementación– ¿Se usa un algoritmo estándar y robusto? ¿Es el apropiado?– ¿Todas las claves, certificados y passwords están correctamente almacenados y

protegidos?– ¿Tiene lugar una distribución segura de claves y un efectivo plan para cambio de éstas?– Analizar código de encriptación para detectar fallas

Evitar el almacenamiento inseguro

Ilustración de protección insuficiente de la capa de transporte

Custom Code

Empleados

Socios de negocioVíctima externa

Backend Systems

Atacante externo

1Atacante interno roba credenciales de acceso y datos fuera de la red

2

Atacante interno roba credenciales de acceso y datos desde la red interna

Atacante interno

• Protegerse con mecanismos adecuados– Usar TLS en todas las conexiones con datos sensibles– Usar HSTS (HTTP Strict Transport Security)– Usar key pinning (browser “marca” certificado de servidor para verificación futura)– Encriptar mensajes antes de transmitirlos

• XML-Encryption– Firmar mensajes antes de transmitirlos

• XML-Signature

• Usar los mecanismos correctamente– Usar algoritmos estándar y robustos– Manejar adecuadamente claves y certificados digitales– Verificar certificados SSL antes de usarlos

• Ver http://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet para más detalles.

Evitar protección insuficiente de la capa de transporte

A7 – Control de acceso a nivel de función inexistente

• Obligando a una efectiva “Autorización”

¿Cómo protéger el acceso a las URLs (páginas)?¿O a las funciones referidas por una URL más parámetros?

• Mostrar sólo links y opciones de menú autorizadas• El control de acceso a nivel de capa de aplicación no funciona• El atacante logrará tener aceso directo a páginas no autorizadas.

Un error común

• Los atacantes invocan funciones y servicios a los que no están autorizados

• Acceso a otras cuentas de usuarios y datos• Efectuar acciones con privilegios sobre el sistema

Impacto típico

• El atacante se da cuenta que la URL indica su rol

/user/getAccounts

• Modifica la URL para accede a otro directorio (rol) /admin/getAccounts, ó

/manager/getAccounts

• El atacante accede a más cuentas que las que su propio rol

Ilustración de Control de acceso a nivel de función inexistente

• Por función, un sitio necesita hacer 3 cosas:– Restringir acceso a usuarios autenticados (si no es público)– Aplicar permisos basados en usuarios o roles (si es privado)– No permitir requerimientos a tipos de páginas no autorizados (ej. archivos de

configuración, logs, archivos fuente)

• Verificar su arquitectura– Usar un modelo simple en cada capa– Asegúrese que realmente tienen un mecanismo de control de acceso en cada capa

• Verifique la implementación– Verifique que cada URL (además de los parámetros) referencian a una función que es

protegida por:• Un filtro externo, como JavaEEweb.xml• Verificaciones internas en el código (ej. usar método de ESAPI

isAuthorizedForURL())– Verificar que la configuración de servidor desactiva requerimientos a tipos de archivos

no autorizados.– Usar OWASP ZAP para detectar acceso a páginas o archivos no autorizadas

Evitar Control de acceso a nivel de función inexistente

A8 – Solicitud de falsificación a través de sitios (CSRF)

• Un ataque donde se engaña al browser de la víctima hacia una aplicación web vulnerable.

• La Vulnerabilidad es causada porque los browser almacenan y escriben automáticamente datos de autenticación de l usuario (Session ID, IP, Credenciales de login) con cada request.

Cross Site Request Forgery

• Iniciar transacciones (transferir dinero, cerrar cuenta, cerrar sesión)• Acceso a datos sensibles• Cambiar información de cuentas

Impacto típico

CSRF Patrón de vulnerabilidad

• El problema– Los navegadores automáticamente incluyen credenciales en cada

requerimiento.– Incluso para requerimientos causados por un formulario, script o imagen

en otro sitio web.

• Todos los sitios que descansan solamente en credenciales automáticas son vulnerables.

• Entrega automática de credenciales– Cookie de sesión– Header de autenticación básica– Dirección IP– Certificados SSL del lado del cliente– Autenticación de dominio de Windows

Ilustración CSRF

3

2

El Atacante pone la trampa en un sitio web o la envía por email1

Mientras inicia sesión en el sitio vulnerables, la víctima ve el sitio del atacante.

El sitio vulnerable ve un request desde la víctima y efectúa la acción solicitada.

La etiqueta <img> cargada por el browser envía un request GET (incluyendo credenciales) al sitio vulnerable.

Custom Code

Acco

unts

Fina

nce

Adm

inis

trati

onTr

ansa

ction

sCo

mm

unic

ation

Know

ledg

e M

gmt

E-Co

mm

erce

Bus.

Fun

ction

s

Etiqueta <img> oculta que contiene un ataque contra el sitio vulnerable

Aplicación con vulnerabilidad CSRF

• Agregue un token secreto a todos los requests sensibles (no debe ser automáticamente enviado)

– Hace imposible que el atacante modifique el requerimiento– Los tokens debieran ser robustos criptográficamente

• Opciones– Almacenar un token en la sesión y agregarlo a todos los formularios y links

• Campo oculto: <input name="token" value="687965fdfaew87agrde" type="hidden"/>

• URL: /accounts/687965fdfaew87agrde• Token en el formulario: /accounts?auth=687965fdfaew87agrde …

– Se puede usar un token por cada función• Usar un hash del nombre de la función, session id y la password

– Puede requerir autenticación secundaria para funciones sensibles• No permitir que los atacantes almacenen código malicioso en su sitio web

– Codificar todas las entradas antes de enviar los datos– Esto hace que todos los links y solicitudes sean inertes ante el intérprete

Para mayores detalles revisar:www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet

Evitar fallas CSRF

Todos usan bibliotecas vulnerables29 MILLION vulnerable

downloads in 2011

Libraries 31Library Versions

1,261

Organizations 61,807Downloads 113,939,358

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

A9 – Usar componentes vulnerables

• Algunos componentes vulnerables pueden ser identificados y explotados con herramientas automatizadas

Los componentes vulnerables son comunes

• Virtualmente cada aplicación tiene estos problemas• En muchos casos, los desarrolladores ni siquiera conocen todos los componentes que

usan

Expansión

• Completo rango de debilidades• Impacta completamente el sistema

Impacto típico

¿Qué se puede hacer para evitarlo?

• Verificaciones automáticas periódicamente• Que le informe las vulnerabilidades conocidas

Ideal

• Chequeo periódico manual y upgrade consecuente• Si alguna está desactualizada, pero no quiere actualizar, verificar si existen problemas

de seguridad para esa biblioteca

Mínimo

• Verificar bases de datos de vulnerabilidades como CVE.• Actualizar si corresponde

También podría ser

A10 – Redirecciones y reenvíos no validados

• Y frecuentemente usan parámetros entregados por el usuario en la URL destino. Si no son validados, el atacante puede enviar a la víctima a un sitio de su preferencia.

Las redirecciones de aplicaciones web son muy comunes

• Internamente envían los request a una nueva página en la misma aplicación

• A veces los parámetros los define la página destino• Si no son validados, un atacante puede usarlo para saltar verificaciones

de autenticación.

Los reenvíos también son comunes (Transferencia en .NET)

• Redirigir a la víctima a un sitio phishing o malicioso• El requerimiento del atacante es reenviado para pasar por alto

verificaciones de seguridad, permitiendo funciones no autorizadas o acceso a datos restringidos

Impacto típico

Ilustración de redirección no validada

3

2

Se envía el ataque vía email o por página web

From: Internal Revenue ServiceSubject: Your Unclaimed Tax RefundOur records show you have an unclaimed federal tax refund. Please click here to initiate your claim.

1

La aplicación redirecciona a la víctima al sitio del atacante

El request se envía a un sitio vulnerable, incluyendo el sitio destino del atacante como parámetro. La redirección envía a la víctima al sitio del atacante.

Custom Code

Acc

ount

s

Fina

nce

Adm

inis

trati

on

Tran

sacti

ons

Com

mun

icati

on

Know

ledg

e M

gmt

E-Co

mm

erce

Bus.

Fun

ction

s

4El sitio malicioso instala malware en la víctima o extrae información privada por phishing

La víctima selecciona el link que contiene parámetros no validados

Evil Site

http://www.irs.gov/taxrefund/claim.jsp?year=2006&

… &dest=www.evilsite.com

Ilustración de reenvío no validado

2

El atacante envía un ataque a la página vulnerable a la cual tiene acceso1

La aplicación autoriza el request la cual continúa a la página vulnerable

El request se envía a una página vulnerable a la cual el usuario tiene acceso. La redirección envía al usuario directamente a la página privada, saltándose el control de acceso

3 La página reenviada falla en validar el parámetro, enviando el atacante a una página no autorizada, saltándose el control de acceso.public void doPost( HttpServletRequest request,

HttpServletResponse response) {try {

String target = request.getParameter( "dest" ) );

...

request.getRequestDispatcher( target ).forward(request, response);

}catch ( ...

Filtro

public void sensitiveMethod( HttpServletRequest request, HttpServletResponse response) {

try {//

Do sensitive stuff here....

}catch ( ...

1. Evitar usar redirecciones y reenvíos2. Si se usan, no involucrar parámetros de usuario en la definición de la URL destino3. Si debe incluír parámetros de usuario:

a) Valide cada parámetro para asegurarse que es válido y autorizadob) Use asignación del lado del servidor para traducir la opción provista al usuario con la página actual.

– Defensa en profundidad: Para redirecciones, valide la URL destino después que sea determinada y asegúrese que dirige a un sitio externo autorizado

– ESAPI lo puede hacer por usted• Ver: SecurityWrapperResponse.sendRedirect( URL )• http://owasp-esapi-java.googlecode.com/svn/trunk_doc/org/owasp/esapi/filters/

SecurityWrapperResponse.html#sendRedirect(java.lang.String)

• Algunas ideas acerca de proteger reenvíos– Idealmente, debiería llamar el controlador de acceso para asegurarse que el usuario está

autorizado antes de que usted efectúe el reenvío.– Con un filtro externo, como Siteminder, no es muy práctico.– Lo mejor es asegurarse que los usuarios que pueden acceder la página original están

autorizados a acceder a la página destino.

Evitar Redirecciones y reenvíos no validados

• Desarrollar código seguro– Seguir las mejores prácticas en la guía para construir aplicaciones Web seguras de

OWASP• https://www.owasp.org/index.php/Guide• Y las hojas de apuntes: https://www.owasp.org/index.php/Cheat_Sheets

– Use el estándar de verificación de seguridad de aplicaciones de OWASP para asegurar una aplicación

• https://www.owasp.org/index.php/ASVS– Use componentes estándar de seguridad que calzan con su organización

• Use ESAPI OWASP como base para sus componentes estándar• https://www.owasp.org/index.php/ESAPI

• Revise sus aplicaciones– Tenga un team de expertos para revisar sus aplicaciones– Revise usted mismo sus aplicaciones siguiendo las guías de OWASP

• Guía de revisión de código de OWASP: https://www.owasp.org/index.php/Code_Review_Guide

• Guía de pruebas de OWASP: https://www.owasp.org/index.php/Testing_Guide

Resumen. ¿Cómo lidiar con estos problemas?

GraciasOWASP Top-10 2013