(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
Top Related