66.69 Criptografía y Seguridad Informática 1er. Cuatrimestre 2011 Top 5 OWASP + WAF 66.69 Criptografía y Seguridad Informática 1er. Cuatrimestre 2011 Cristian

OWASP Organización focalizada en mejorar la seguridad de las aplicaciones de software. Consenso general sobre cuáles son las vulnerabilidades más críticas de las aplicaciones web. Incluye una lista de las diez vulnerabilidades más críticas. Cristian

OWASP Top Ten (2010 Edition) A1: Injection A2: Cross-Site Scripting (XSS) A3: Broken Authentication and Session Management A4: Insecure Direct Object References A5: Cross Site Request Forgery (CSRF) A6: Security Misconfiguration A7: Failure to Restrict URL Access A8: Insecure Cryptographic Storage A9: Insufficient Transport Layer Protection A10: Unvalidated Redirects and Forwards Cristian

Mutillidae Herramienta didáctica para ilustrar el Top 10 Hecha en PHP/MySQL Simple de explotar Fácil de restaurar Incluye tips de ayuda para explotar y entender las distintas vulnerabilidades Cristian

A1 - SQL Injection Andres

SQL Injection Se inserta o "inyecta" código SQL invasor dentro del código SQL programado, a fin de alterar el funcionamiento normal del programa y lograr así que se ejecute la porción de código "invasor" en la base de datos. Ocurre cuando… Reciben strings y los interpretan como comandos SQL, OS Shell, LDAP, XPath, Hibernate, etc… Intérpretes… Muchas aplicaciones continúan siendo vulnerables A pesar que es muy simple de evitar SQL injection sigue siendo muy común Usualmente severo. La base de datos puede ser leída por completo, o modificada. Impacto típico Andres

"SELECT * FROM accounts WHERE acct=‘’ OR 1=1--’" SQL Injection Account: SKU: Account: SKU: "SELECT * FROM accounts WHERE acct=‘’ OR 1=1--’" Account Summary Acct:5424-6066-2134-4334 Acct:4128-7574-3921-0192 Acct:5424-9383-2039-4029 Acct:4128-0004-1234-0293 HTTP response   DB Table   HTTP request SQL query Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions Application Layer Databases Legacy Systems Web Services Directories Human Resrcs Billing APPLICATION ATTACK Custom Code 1. La aplicación muestra un formulario 2. El atacante ingresa una consulta SQL maliciosa en algún campo del formulario App Server Andres 3. La aplicación reenvía dicha consulta al motor de base de datos Web Server Hardened OS Network Layer 4. El motor de la BD ejecuta la consulta con código malicioso y envía los resultados a la aplicación Firewall Firewall 5. La aplicación muestra los resultados al usuario

Demo Andres

Métodos de Prevención Escapar las variables antes de ser enviadas al intérprete Parametrizar las sentencias sql Realizar una “white list” de validación para los datos ingresados por el usuario Acotar los privilegios de la base de datos para reducir el impacto Andres

A2 – Cross-Site Scripting (XSS) Tifi

XSS Una aplicación toma datos ingresados por el usuario y los envía al navegador sin previo encoding ni validación. Permite ejecutar scripts en el navegador de la víctima permitiendo el robo de cookies de sesión, ejecución de virus, etc. Ocurre cuando… Guardados en la base de datos Reflejados desde los inputs de la aplicación (form field, hidden field, URL, etc.) Envíados directamente embebiendo código javascript Tipos de ataques Robo de cookies de sesión, robo de datos sensibles, sobreescritura de páginas web, Phishing Crítico: Instalación de un proxy XSS el cual permite al atacante observar el comportamiento de un usuario en un sitio vulnerable y forzarlo a ingresar a otros sitios. Impacto típico Tifi

XSS 1 El atacante prepara la trampa – “Mi Perfil” Aplicación vulnerable a XSS (guardado) El atacante ingresa un script malicioso dentro de una página web que almacena los datos en el servidor Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions 2 La víctima ingresa al perfil del atacante - “Mi Perfil” Tifi El script corre en el browser de la víctima con acceso completo al DOM y a las cookies 3 El script envía (silenciosamente) la cookie de sesión de la víctima al atacante

Demo Tifi: Flash + Phishing

Métodos de Prevención No mostrar directamente los datos ingresados por el usuario Encode a la salida de los datos ingresados por el usuario Frameworks: filtrado y validación automática Enterprise Security API Creado por OWASP Provee un conjunto de interfases para encode y validación de datos Disponible en varios lenguajes. AntySamy API para sanitizar HTML Modelo de protección “white list” Fácil de usar Toma un html/css crudo y lo retorna seguro Tifi que validar en todos los lugares en los que se tomen valores del querystring, del form, de una base de datos, de una cookie, o de las variables Session y Application, y luego se escriben en el response.

A3 – Broken Authentication and Session Management Lau Incluye todos los aspectos del tratamiento de la autenticación del usuario y el manejo de sesiones activas.

Broken Authentication and Session Management El SESSION ID es usado para trackear el estado en HTTP El SESSION ID está expuesto en las redes, navegadores, etc. Métodos no estandarizados de autenticación Ocurre cuando… Las credenciales viajan en cada request Se debe usar SSL cuando se requiera autenticación HTTP es “stateless” Los cambios de password, recordarme, olvidé mi password, pregunta secreta, logout, email, etc… Proteger… Severo: Se comprometen cuentas y sesiones de usuario Impacto típico Lau Password Strength - passwords deben tener restricciones, de tamaño mínimo y complejidad. La complejidad implica combinaciones alfanumericas, etc. Los usuarios deben cambiar periodicamente le pass y no usar pass anteriores. Password Use - Restringir nro de intentos x unidad de tiempo. No indicar si el user o pass fueron fallidos. Los usuarios deben ser informados de la ultima vez que se loguearon con exito y la cant de login fallidos a ese momento. Password Change Controls - Proveer un mecanismo simple de cambio de pass, e indicar siempre old pass y new pass en el proceso, ademas de toda la info de cuenta. Password Storage - Todos los pass deben ser guardados hasheados o encriptados. Hash es bueno xq es irreversible, pero la encripcon es necesaria cunado se necesita el pass en txt plano, para x ej loguearse en otro sistema. Los pass nunca deben estar hardcodeados en el codigo. Protecting Credentials in Transit - La unica técnica efectiva es encriptar toda la transaccion de login con algo como SSL. Ya que a pesar de usar hash este puede ser interceptado y retransmitido. Session ID Protection – Idealmente la sesión del usuario debe ser protegida x ssl, pero si ssl no es viable x razones de performance o otrras razones el session id debe ser protegido de otras maneras. NUNCA incluirlo en las urls, o reenviar las urls a “amigos”. El session ID debe ser largo, complicado y random. Session id elegido x los usuarios nunca debe ser aceptado. Account Lists -Evitar mostrar la lista de usuarios, si se usa usar pseudonimos que mapeen a los nombres de usuarios reales, los pseudonimos no deben servir como username para loguearse. Browser Caching – Authentication and session nunca deben ser submiteadas por GET, usar POST. Authentication pages no deberian cachearse para evitar el “back button”. Trust Relationships – Your site architecture should avoid implicit trust between components whenever possible. Each component should authenticate itself to any other component it is interacting with unless there is a strong reason not to (such as performance or lack of a usable mechanism). If trust relationships are required, strong procedural and architecture mechanisms should be in place to ensure that such trust cannot be abused as the site architecture evolves over time.

Broken Authentication El usuario envía credenciales y reserva un viaje en una agencia 1 Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions http://tourism.com/sale/saleitems; jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii El sitio reescribe la url concatenando el session id 2 Lau 3 El usuario reenvía el link a sus amigos Cuando sus amigos ingresen al link usarán su sesión y su tarjeta de crédito 4

Demo Lau: Cookies stealing Lau: Agregado y edición de cookie

Métodos de Prevención Autenticación simple, centralizada y estandarizada SSL para proteger credenciales y session id en todo momento Verificar que el logout destruya la sesión Usuarios y passwords encriptados en la base de datos Configuración adecuada del timeout de sesión Evitar vulnerabilidades XSS Lau

A4 – Insecure Direct Object References Dami Una referencia directa insegura a objetos ocurre cuando un desarrollador expone una referencia a un objeto de implementación interno, tal como un fichero, directorio, o base de datos. Sin un chequeo de control de acceso u otra protección, los atacantes pueden manipular estas referencias para acceder datos no autorizados.

Insecure Direct Object References Un desarrollador expone referencias a la implentación interna de un archivo, directorio, registro de base de datos, claves, url’s, etc. Los atacantes pueden manipular esas referencias y acceder a contenido no autorizado. Ocurre cuando… Accesos a objetos Referencias (deben ser indirectas) Proteger… Severo: Acceso a información no autorizada Impacto típico Dami

Insecure Direct Object References El atacante decubre que su número de cuenta es 6065 Lo modfica por otro valor ?account=6066 El atacante logra acceder a otra cuenta https://www.onlinebank.com/user?account=6065 Dami

Demo Dami Una aplicación presenta una referencia directa insegura a objetos, por ejemplo, una lista con posibles documentos que pueden ser seleccionados para ser visualizarlos, donde cada entrada de la lista referencia directamente a un fichero del sistema de archivos. Un atacante, como usuario autorizado en el sistema, simplemente modifica el valor de un parámetro (uno de esos documentos) que se refiere directamente a un objeto del sistema a otro objeto para el que el usuario no se encuentra autorizado.

Métodos de Prevención Eliminar referencias directas Reemplazarlos por mapeos temporales Interfaz ESAPI para mapero indirecto Validar referencias directas Verificar que el usuario tiene acceso al recurso Dami

A5 – Cross Site Request Forgery (CSRF) Andres

CSRF EL navegador de la victima logueada envía un request pre-autenticado a una aplicación vulnerable, la cual fuerza al navegador a realizar acciones en beneficio del atacante Ocurre cuando… Idem XSS Proteger Severo: Acceso a información sensible Severo: Cambio de datos de cuenta Impacto típico Andres Proteger… No mostrar directamente los datos ingresados por el usuario Encode a la salida de los datos ingresados por el usuario Enterprise Security API Creado por OWASP Provee un conjunto de interfases para encode y validación de datos Disponible en varios lenguajes. AntySamy API para sanitizar HTML Modelo de protección “white list” Fácil de usar Toma un html/css crudo y lo retorna seguro

CSRF 1 El atacante prepara una trampa para un sitio web vulnerable La aplicación tiene la vulnerabilidad CSRF Un tag oculto <img> contiene un ataque embebido Custom Code Accounts Finance Administration Transactions Communication Knowledge Mgmt E-Commerce Bus. Functions 2 El usuario logueado ingresa al sitio del atacante Andres 3 El sitio vulnerable al ver el request legítimo de la víctima, ejecuta la acción. El tag <img> cargado por el browser envía por GET las credenciales al sitio vulnerable

Demo Andres

Métodos de Prevención Agregar un nonce por request (Number used once) a la URL y a todos los formularios Los tokens deben ser criptográficamente fuertes. No utilizar request del tipo GET (URL) para datos o transacciones importantes. Utilizar POST, aunque esto solo no es suficiente. Verificar que el request HTTP provenga del sitio original Andres

ESAPI Dami – Lau Método de prevención de código abierto. Es una solución open source multi-plataforma. Provee soporte para la mayoría de los lenguajes y es muy simple. Incluye todo lo necesario para proteger una app de las vulnerabilidades detalladas en el top 10 de owasp.

Interfaces para Top 5 ESAPI OWASP Top 5 OWASP ESAPI A1. SQL Injection A2. Cross Site Scripting (XSS) A3. Broken Authentication and Sessions A4. Insecure Direct Object Reference A5. Cross Site Request Forgery (CSRF) OWASP ESAPI Encoder Validator, Encoder Authenticator, User, HTTPUtils AccessReferenceMap, AccessController User (CSRF Token) Dami – Lau Encoders: reemplazan caracteres conflictivos por &entity; o por su representación en hexadecimal Validator: valida que la entrada matchee con el tipo de dato esperado Authenticator: User: HTTPUtils: set of helper functions related to HTTP requests, responses, sessions, cookies, headers, and logging AccessReferenceMap: para generar referencias indirectas y vincularlas a referencias directas AccessController: para controlar si se tiene acceso al recurso (autorización)

Input Validation Dami

Output Validation Dami

Esquema de encoding con ESAPI #1: ( &, <, >, " )  &entity; ( ', / )  &#xHH; ESAPI: encodeForHTML() HTML Element Content (e.g., <div> some text to display </div> ) #2: All non-alphanumeric < 256  &#xHH ESAPI: encodeForHTMLAttribute() HTML Attribute Values (e.g., <input name='person' type='TEXT' value='defaultValue'> ) #3: All non-alphanumeric < 256  \xHH ESAPI: encodeForJavaScript() JavaScript Data (e.g., <script> some javascript </script> ) Dami - Lau ALL other contexts CANNOT include Untrusted Data Recommendation: Only allow #1 and #2 and disallow all others See: www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet for more details #4: All non-alphanumeric < 256  \HH ESAPI: encodeForCSS() HTML Style Property Values (e.g., .pdiv a:hover {color: red; text-decoration: underline} ) #5: All non-alphanumeric < 256  %HH ESAPI: encodeForURL() URI Attribute Values (e.g., <a href="javascript:toggle('lesson')" )

Demo Dami – Lau SQL: process-login-attempt.php (linea 18) XSS: view-someones-blog.php (linea 170) BA: process-login-attempt.php (linea 50) IDOR: source-viewer.php (linea 79, 198) CSRF: source-viewer.php (linea 60, 145) Dns-lookup.php (linea 35) Add-to-your-blog.php (linea 68, 86, 181)

WAF Cristian

Características principales Filtro que aplica un conjunto de reglas a una comunicación HTTP Controla entradas, salidas y accesos Buena (y única) solución para enlatados Falsos positivos  Soporta seguridad con listas negras y listas blancas. Alta performance. Cristian

Configuración #Preventing Cookie Stealing, CSRF Post and Phishing attack SecRule ARGS “<script” #Preventing CSRF Post Iframe SecRule ARGS “<iframe” #Preventing Flash attack SecRule ARGS “<embed” #Preventing CSRF Get attack SecRule ARGS "<img“ #Preventing SQL Injection and Broken Authentication and Session Management SecRule ARGS "'.+=.+--“ SecRule ARGS "select.+from“ #Preventing Insecure Direct Object Reference SecRule ARGS "\.\./“ SecRule ARGS ";[[:space:]]*(ls|id|pwd|wget|dir)”

Demo Cristian

Conclusiones Desarrollar código seguro Revisar las aplicaciones Seguir las best practices de la guía de OWASP’s de como construir una aplicación web segura http://www.owasp.org/index.php/Guide Usar OWASP’s Application Security Verification Standard como guía para saber las necesidades de seguridad http://www.owasp.org/index.php/ASVS Usar componentes estandar (ESAPI) http://www.owasp.org/index.php/ESAPI Revisar las aplicaciones Tener un experto en el equipo que revise las aplicaciones Seguir las guías propuestas por OWASP OWASP Code Review Guide: http://www.owasp.org/index.php/Code_Review_Guide OWASP Testing Guide: http://www.owasp.org/index.php/Testing_Guide Cristian - Tifi