Javier Saez - Una panorámica sobre la seguridad en entornos web [rootedvlc2]

1Rooted Satellite Valencia

Una panorámica sobre seguridad en entornos web

Satellite Edition


Guía de presentación1.- Introducción.2.- El ecosistema web.3.- Vulnerabilidades y explotación.4.- Buenas prácticas.5.- Herramientas, recursos y créditos.


1.- Introducción¿A quien se enfoca la charla?

– Newcomers. Empezamos con una buena base.

– Experienced. Ya llevamos un tiempo programando, pero la seguridad ha sido circunstancial.

– Todo el mundo. ¡Aprende a mirar y navega seguro!


El terrenoComo desarrollador web, como en todo, hay mucho que aprender:– Servidores– Programación Back-end– Programación Front-end– Metodologías y paradigmas.– Otros (maquetación, SEO, etc…)

La especialización viene después.


Las armasServidores– Java (Tomcat, Glassfish), PHP (Apache, nginx,

etc…)Lenguajes de programación– Front-end (Javascript), Back-end (PHP, Java,

Phyton, etc…)Frameworks: – Java (Spring, Struts), PHP (CodeIgniter, Laravel,

Zend), Phyton (Django), etc…Conviene conocer y manejar unos cuantos.


El dueloConocer, comprender y dominar las herramientas.Practicar.Leer.


From scratch vs FrameworksMe gusta hacerlo todo por mí mismo.– No hay dependencias con nada/nadie.– Recopilación de código genérico.– Framework propio.

Uso de frameworks:– No hay necesidad de reinventar la rueda.– Solución a problemas que aun ni conocemos.– Soporte de la comunidad.


2.- El ecosistema webNos vamos a centrar en los ataques directos sobre aplicaciones web, pero repasamos algunos puntos de seguridad en servidores. En todos los puntos puede existir una vulnerabilidad explotable.– Mala configuración. – Herramientas/contenido instalad@s por

defecto. – Puertos/Servicios habilitados sin necesidad.


SituacionesEn empresas de hosting, es su responsabilidad proporcionar un entorno seguro (a priori). Entornos de prueba, servidores caseros, empresas pequeñas, hostings propios, etc… Es nuestra responsabilidad.


Algunas precauciones (Xampp)Desactivar directivas innecesarias (según caso):– Listado de directorio – (-)Indexes – Ejecución de CGI – (-)ExecCGI– Restricción de acceso a directorios. (Order, Allow)– Métodos HTTP (DELETE, PUT, TRACE, etc…)

Cambiar/Establecer contraseñas.Php.iniMod_security (Apache WAF)


Algunas precauciones (Tomcat)

Contenedor de aplicaciones Java (Tomcat, incluido en Xampp)– Establecer usuario/grupo/permisos– (Des)Habilitar los conectores/métodos

(in)necesarios.– Ajustar variables en archivo server.xml

• maxPostSize, maxHttpHeaderSize….• Ocultar información (server y xpoweredBy)• Desactivar allowTrace (HTTP TRACE)

– Tratamiento adecuado de excepciones


3.- Vulnerabilidades webBasado en el informe "Top 10 OWASP 2013"Formato:– Descripción de la vulnerabilidad– Principales medidas de protección.– Ejemplos.


3.1.- Cross-site scripting (XSS)Aprovecha un incorrecto filtrado de los datos enviados por un usuario para modificar la respuesta del servidor.Principalmente se transporta por url (GET), pero también se puede explotar por formularios POST.Inyecta un código en la página que se ejecuta cuando un usuario accede.El atacante tiene un servidor controlado que actúa como receptor de la información enviada por las víctimas.Difusión de un enlace manipulado. Redes sociales, campañas de mailing, etc…


XSS - TiposReflejado: Una URL transporta un parámetro modificado que actúa al ser accedido por un visitante. Persistente: Se da al guardar en una BD el payload, disparándose cada vez que un usuario visita la página.Basado en DOM: El payload no es procesado por el servidor, sino directamente por el cliente, al ser una etiqueta de la URL.


XSS Reflejado


XSS Persistente


XSS Basado en DOM


ProtecciónNUNCA confiar en los datos de usuario.Asegurarse de filtrar todos los datos recibidos, oUsar herramientas que gestionen la sanitización y el filtrado.Filtrar '<', '>' y métodos js como atributos.Por ejemplo:– CodeIgniter: clase configurable para el filtrado.– Laravel, Blade y “{{ }}” vs “{!! !!}”– Htmlentities() y htmlspecialchars() en PHP


3.2.- SQL InjectionSe da cuando un dato enviado no es filtrado adecuadamente, y es usado en una cadena SQL.No se limita a SQL. Puede darse en LDAP, Xpath (XML), NoSQL, etc…Según la gravedad, puede comprometer toda la base de datos, el servidor de BD’s, estructura de los datos y la privacidad de los usuarios.


SQL Injection - Ejemplos


ProtecciónNUNCA confiar en

los datos de usuario.Asegurarse de escapar todas las comillas \' \"Prepared Statmenets en ORM’s como Hibernate.Frameworks y CMS’s incorporan sus propios ORM’s o hacen uso de terceros.


Ejemplos

XPath - Caracteres prohibidos

Hibernate (Java) - Prepares Statements

PHP - PDO Prepared Statements


3.3.- Autenticación/SesionesPerdida de autenticación. Fallos en la protección de usuarios y contraseñas, y en los procesos relacionados con la autenticación

Gestión de sesiones. Todo lo relacionado con la forma de un servidor de gestionar los identificadores se sesión de un usuario.


Perdida de autenticaciónAgrupa todo lo referente a:– Cifrado de contraseñas.– Lógica de usuarios.

• Creación de usuarios.• Recuperación/Cambio de contraseña.• Autenticación automática.

Conviene agrupar todas las funciones en un solo modulo para limitar los fallos y facilitar el mantenimiento.


Gestión de sesionesConfigurar/revisar/optimizar los mecanismos de asignación y gestión de ID de sesión.Evitar:– Sesiones precedibles.– Otras vulnerabilidades (XSS, login sobre HTTPS

pero navegación sobre HTTP) que pueden capturar la sesión.

– La sesión no debe ser la misma para un usuario antes y después de logearse. (Fijación de sesión)

– HttpOnly


Ejemplo de fijación de sesión


3.4.- Referencias insegurasCuando la lógica del software no controla quien accede a que (objetos).Cuando un usuario puede realizar operaciones que no debería (funciones).Supongamos:– Dos tipos de usuarios A y B.– Dos tipos de Objetos A' ∈ A y B' ∈ B.– Dos tipos de operaciones Visualizar ∈ (A, B) y

Borrar ∈ (B).


Este día estaba matemático....


ObjetosUna vulnerabilidad de Ref. Insegura a Objetos se daría cuando, un sistema donde:– pruebas.com/user/A/view/itemA's • pruebas.com/user/B/view/itemB's

Permite que: – pruebas.com/user/A/view/itemB's – pruebas.com/user/B/view/itemA's

Puede ser directa (ejemplo), o indirecta, donde objeto C' perteneciente a A' pero solo gestionable por usuarios B puede ser gestionado por un usuario A.


FuncionesSemejante a las referencias a objetos pero con las funcionalidades:– pruebas.com/user/A/create/itemA's – pruebas.com/user/B/edit/itemA's – pruebas.com/user/B/delete/itemA's

Se daría si el usuario A pudiera modificar la URL para acceder a:– pruebas.com/user/A/delete/itemA's


ConsideracionesPara protegerse hay que diseñar una estructura clara de permisos y propiedades.Para cada operación hay que preguntarse:– ¿Quién es?– ¿Este objeto le pertenece?– ¿Tiene permiso para realizar esta operación?


3.5.- Configuraciones incorrectas

Ya se ha mencionado lo que respecta a servidores en el punto dos.Cuando la aplicación web está creada from scratch, cada equipo de desarrolladores es responsable de crear un entorno seguro.Al usar Frameworks o CMS's, hay que atender a las opciones de configuración (claves criptográficas, configuración de base de datos, subida de archivos, etc...)


EjemplosWordpress define unas claves para la gestión de los hashes de passwords y autenticaciones.

CodeIgniter tiene una clase para la gestión criptográfica de los datos.


3.6.- Exposición de datos sensibles

HTTP es un protocolo abierto, y la información viaja en texto plano.Cualquier dato de carácter confidencial debería viajar cifrado tanto desde el cliente (externo) como internamente. (HTTPS, otros)La generación de hashes (md5, base64) no bastan por si mismas. AES, Twofish, Serpent...


3.7.- CSRF (XSRF)Un sitio web contiene una petición oculta a otra web, que el cliente ejecuta al visitar la primera.La petición es ejecutada por el usuario como propia.La víctima debe estar logeado en la web objetivo.


Ejemplos


ProtecciónUsar un token único para cada operación y usuario.Doble autenticación o uso de CAPTCHAS para operaciones sensibles.


3.8.- Componentes vulnerablesUsar versiones actualizadas:– Navegadores– Lenguajes de programación.– Frameworks, CMS’s– Plugins de los anteriores, etc…

Revisar CVE, comunidades, foros especializados.


3.9.- Redirecciones y reenvíos.Se manda a los usuarios de un sitio a otro de una web (interno), o a otro sitio (externo).El destino es obtenido mediantes datos del usuario.Incorrecto filtrado de datos.


Ejemplos CRLF / HTTP Response Splitting. Obtiene dos respuestas del servidor a una solicitud, sobreescribiendo la primera.Se da cuando las cabeceras contienen doble \r\n (%0d%0a )– Defacements– Cache Poisoning– Page Hijacking


CRLF


ProtecciónFiltrar caracteres \r\n en distintas codificaciones.Validar el dato que determina la redirección, asegurando que sea válido y autorizado.Usar sistemas de mapeo de url’s o routing, y redireccionar a esos valores.


4.- ConclusionesUsar herramientas que incluyan contramedidas.– Comprobación de vulnerabilidades.– Versiones actualizadas.

Si se va a trabajar from scratch, blindar sectores críticos.Trabajar sobre HTTPS siempre que se traten datos sensibles.


Conclusiones (2)No confiar NUNCA en los datos del usuario.No confiar NUNCA

en los datos del usuario (es que son el doble de…)

Filtrar adecuadamente los datos recibidos para todas las peticiones.


5.- WarehouseOWASP, documentación y ZAP.Plugins Firefox:– Data Tamper.– Proxy Selector

Prácticas:– PentesterLab– Damn Vulnerable Web Application– http://amanhardikar.com/mindmaps/Practice.ht

ml

http://amanhardikar.com/mindmaps/Practice.html

http://amanhardikar.com/mindmaps/Practice.html


Agradecimientos y fuentesRootedCONOWASPSecurity By DefaultSecurity Art Work (Bastionados)Y muchos más…


¡Gracias!

Javier Saez - Una panorámica sobre la seguridad en entornos web [rootedvlc2]

Technology

Transcript of Javier Saez - Una panorámica sobre la seguridad en entornos web [rootedvlc2]