Desarrollo de aplicaciones seguras

2,189 views

Published on

Published in: Technology
  • Be the first to comment

Desarrollo de aplicaciones seguras

  1. 1. Curso: 5007427 (28585) Diseno de aplicaciones seguras (Bloque Servicios Web y seguridad informatica) Fernando Tricas Garc´ ıa Departamento de Inform´tica e Ingenier´ de Sistemas a ıa Universidad de Zaragoza http://www.cps.unizar.es/~ftricas/ ftricas@unizar.es Departamento de Inform´tica e Ingenier´ de Sistemas (Univ. a ıa Zaragoza) - Curso: Desarrollo de aplicaciones seguras 1
  2. 2. Introducci´n o Fernando Tricas Garc´ ıa Departamento de Inform´tica e Ingenier´ de Sistemas a ıa Universidad de Zaragoza http://www.cps.unizar.es/~ftricas/ ftricas@unizar.es Departamento de Inform´tica e Ingenier´ de Sistemas (Univ. a ıa Zaragoza) - Curso: Desarrollo de aplicaciones seguras
  3. 3. Un ´ ındice Introducci´n o Gesti´n de riesgos o Selecci´n de tecnolog´ o ıas C´digo abierto o cerrado o Principios Auditor´ de programas ıa
  4. 4. Un ´ ındice (cont.) Desbordamiento de memoria Control de acceso Condiciones de carrera Aleatoriedad y determinismo Aplicaci´n de la criptograf´ o ıa
  5. 5. Un ´ ındice (cont.) Gesti´n de la confianza y validaci´n de entradas o o Autentificaci´n con claves o Seguridad en bases de datos Seguridad en el cliente En la web
  6. 6. Introducci´n. Antes de empezar. o Se invierte mucho tiempo, dinero y esfuerzo en seguridad a nivel de red por la mala calidad de los programas. Algunas veces los cortafuegos, los sistemas de detecci´n de o intrusos (IDS) ayudan. Los programas malos son mucho m´s abundantes de lo que a creemos. La forma de desarrollar los programas es responsable en gran medida del problema.
  7. 7. Cifras El 30 % de los proyectos en entornos empresariales se cancelan sin haber sido finalizados. De los que se terminan, el 30 % cuesta al final entre un 150 % y un 200 % del presupuesto original.
  8. 8. Cifras Menos del 10 % de proyectos en empresas grandes terminan a tiempo, y cumpliendo el presupuesto. Las tasas de defectos en productos comerciales se estiman entre 10 y 17 por cada 1000 l´ıneas de c´digo. o Otras estimaciones: entre 5 y 50 fallos.
  9. 9. M´s cifras a Diciembre de 1990: Miller, Fredrickson. ‘An empirical study of the reliability of Unix Utilities’ (Communications of the ACM, Vol 33, issue 12, pp.32-44). Entre el 25 y el 33 % de las utilidades en Unix pod´ ıan interrumpirse o colgarse proporcion´ndoles entradas a inesperadas. 1995: Miller otra vez, ejecutando Fuzz en nueve plataformas tipo Unix diferentes: Fallos entre un 15 y un 43 % Muchos fallos ya avisados en el 90 segu´ all´ ıan ı La menor tasa de fallos: utilidades de la FSF (7 %) y a las incluidas junto con Linux (9 %) (¿Uh?) No consiguieron hacer fallar ning´n servidor de red. Tampoco u el servidor X Window. Muchos clientes de X, si
  10. 10. Cifras 2000: Miller y Forrester. Fuzz con Windows NT. 45 % de los programas se colgaron o se interrumpieron Enviar mensajes aleatorios Win32 a las aplicaciones hac´ fallar ıa al 100 % Miller, Cooksey y Moore. Fuzz y Mac OS X. 7 % de las aplicaciones de l´ ınea de ´rdenes. o De las 30 basadas en GUI s´lo 8 no se colgaron o se pararon. o
  11. 11. Cifras 2004-2005. Honeypot, con varios sistemas (Windows, Mac, Linux) Windows XP. SP 1. Fue atacado 4857 veces Infectado en 18 minutos (Blaster y Sasser) En una hora era un ‘bot’ controlado remotamente, y comenz´ a realizar sus propios ataques o Feb-Marzo 2005: menos del 24 % de los Windows XP observados en un estudio de AssetMetrix Research Labs ten´ SP2. Menos del 7 % del total lo ten´ 251 empresas ıan ıan. norteamericanas (seis meses desp´s de su lanzamiento). e http://www.stillsecure.com/docs/StillSecure_ DenverPost_Honeypot.pdf
  12. 12. Estudio OpenSSH Julio 2002 se descubri´ un fallo de desbordamiento de o memoria remoto Dos semanas despu´s de la publicaci´n del anuncio del fallo, e o mas de 2/3 de los servidores observados segu´ siendo ıan vulnerables. Septiembre 2002. Un gusano explotaba el fallo (Slapper). El 60 % de servidores era todav´ vulnerable. ıa Security holes. . . Who cares? http: //www.cgisecurity.com/lib/reports/slapper-report.pdf
  13. 13. Introducci´n. Antes de empezar. o Los programas no tienen garant´ (¿todav´ ıa ıa?). La seguridad es un problema de gesti´n de riesgos. o Pensemos en la seguridad durante el dise˜o, despu´s ya es n e tarde.
  14. 14. Puede haber castigo Cada vez se habla m´s de la responsabilidad de las empresas que a desarrollan programas: 1999. Ambrosia Software (Rochester, N.Y.) anunci´ que si alguno o de sus productos requer´ la reparaci´n de errores, el responsable ıan o de marketing comer´ insectos en alguna feria. ıa http://www.ambrosiasw.com/PRs/eatbugs_PR.html Parece que finalmente tuvieron que comerlos . . . http://www.ambrosiasw.com/news/old_newsletter.php?id=34019&page=3 31 de diciembre de 1999. Las autoridades chinas obligaron a los ejecutivos de la compa˜´ a´rea nacional a volar durante esa noche nıa e en los vuelos programados.
  15. 15. ¿Por qu´ es importante? e Cada vez hay m´s computadores y en m´s sitios. a a La gente ni sabe ni quiere saber de estos temas. A´n peor, saben lo que dicen las noticias. u
  16. 16. Son los programas Dependemos (mucho) de los computadores (y sus programas). El principal problema es que la mayor´ de los desarrolladores ıa ni siquiera saben que hay un problema. Ni los cortafuegos ni la criptograf´ resolver´n los problemas ıa a (el 85 % de los avisos del CERT no se pueden prevenir con criptograf´ ıa).
  17. 17. Son los programas (est´pido) u Est´ bien proteger la transmisi´n pero los atacantes prefieren a o los extremos Las aplicaciones que interact´an con Internet son las m´s u a delicadas, pero no es imprescindible que tengan contacto con la red para ser peligrosas.
  18. 18. Son los programas Empezar pronto Conocer las amenazas Dise˜ar pensando en la seguridad n Ce˜ir el dise˜o a los an´lisis de riesgos y las pruebas n n a
  19. 19. Gesti´n del riesgo o La seguridad es un compromiso entre muchos factores: Tiempo hasta que se puede vender Coste Flexibilidad Reutilizabilidad Relaciones entre los anteriores Hay que establecer las prioridades, a veces la seguridad no es la principal necesidad.
  20. 20. Seguro o Inseguro Mucha gente piensa en la seguridad como algo que se tiene o no se tiene. Es muy dif´ probar que un sistema de complejidad mediana ıcil es seguro. Frecuentemente, ni si quiera vale la pena.
  21. 21. Seguro o Inseguro Es mas realista pensar en t´rminos de gesti´n de riesgo: e o ¿Cu´nto riesgo? a ¿Cu´nto cuesta reducirlo? a Recordar: los ’malos’ no crean los defectos, simplemente los utilizan.
  22. 22. Fallos en los programas A˜o 2000: aproximadamente 20 nuevas vulnerabilidades cada n semana Muchas en programas con c´digo, pero otras tantas en las o que no se conoce Unix y Windows tambi´n est´n equilibrados e a Siguen apareciendo problemas en programas probados y usados.
  23. 23. Algunas cifras NIST: National Institute of Standards and Technology NVD: National Vulnerabilities Database http://nvd.nist.gov/statistics.cfm?results=1
  24. 24. M´s cifras a CERT: Organizaci´n del Software Engineering Institute (SEI). o http://www.cert.org/stats/ 18 de febrero de 2008
  25. 25. Y m´s . . . la web a Figure 1. (a) Breakdown of disclosed vulnerabilities by software type in May 2006, and (b) current vulnerability types disclosed in Web-based applications. (Source: SecurityFocus.com) http://www.computer.org/portal/site/security/menuitem.6f7b2414551cb84651286b108bcd45f3/index. jsp?&pName=security_level1_article&TheCat=1015&path=security/2006/v4n4&file=gei.xml Resumida: http://tinyurl.com/3862ba
  26. 26. M´s cifras a http://www.cisco.com/web/about/security/cspo/docs/Cisco2007Annual_Security_Report.pdf
  27. 27. Consecuencias http://www-935.ibm.com/services/us/iss/pdf/etr_xforce-2007-annual-report.pdf
  28. 28. ¿D´nde conocerlos? o Bugtraq (http://www.securityfocus.com/) CERT Advisories http://www.cert.org/ http://www.rediris.es/cert/ Equipo de Seguridad para la Coordinaci´n de Emergencias en o Redes Telem´ticas (http://escert.upc.edu/) a ICAT Metabase (http://nvd.nist.gov/) OSVDB, Open Source Vulnerability Database (http://osvdb.org/) INTECO, http://www.inteco.es/ RISKS Digest (http://catless.ncl.ac.uk/Risks/) Help Net Security http://www.net-security.org/
  29. 29. ¿Y las tecnolog´ ıas? La complejidad introduce riesgos. A˜adir funcionalidades (no presente en el original) n Invisibilidad de ciertos problemas Dificultad para analizar, comprender, asegurar.
  30. 30. Complejidad en navegadores http://www.spinellis.gr/blog/20031003/index.html Mozilla 1.3 // Explorer 5
  31. 31. La complejidad Windows NT → 35 millones de l´ ıneas de c´digo. o Windows XP → 40 millones de l´ ıneas de c´digo. o Windows Vista → 50 millones de l´ ıneas de c´digo. o Linux 2.2 → 1.78 millones, Solaris 7 → 400000. Debian GNU/Linux 2.2 55 millones Red Hat 6.2 17 millones. Mac OS X Darwin 790000 (el kernel)
  32. 32. La complejidad Windows NT → 35 millones de l´ ıneas de c´digo. o Windows XP → 40 millones de l´ ıneas de c´digo. o Windows Vista → 50 millones de l´ ıneas de c´digo. o Linux 2.2 → 1.78 millones, Solaris 7 → 400000. Debian GNU/Linux 2.2 55 millones Red Hat 6.2 17 millones. Mac OS X Darwin 790000 (el kernel) Seguimos programando en C! (en el mejor de los casos C++) Esto va cambiando . . . Java, .Net, . . . Luego hay que instalar, configurar, usar
  33. 33. Complejidad Linux + Apache Windows + IIS http://blogs.zdnet.com/threatchaos/?p=311 Why Windows is less secure than Linux Abril 2006
  34. 34. Complejidad, vulnerabilidades, incidentes, . . . Dan Geer, 2004 http: //www.stanford.edu/class/msande91si/www-spr04/slides/geer.pdf
  35. 35. En red Cada vez m´s redes a Los ataques pueden venir de m´s sitios a Ataques automatizados/autom´ticos a M´s sitios para atacar, m´s ataques, mas riesgo a a
  36. 36. Extensibilidad C´digo m´vil o o ‘Enchufables’ en el navegador (‘plugins’) M´dulos, ‘drivers’ o Muchas aplicaciones tienen lenguajes que permiten extenderlas. Econ´micamente conveniente (reutilizaci´n) pero ... o o
  37. 37. El entorno A˜adir seguridad a un sistema ya existente es casi imposible n Es mejor dise˜ar con la seguridad en mente n Otra fuente de problemas es ‘ambiental’: un sistema completamente seguro en el entorno para el que fue dise˜ado, n deja de serlo en otros.
  38. 38. Pero ... ¿Qu´ es seguridad? e Primero, es importante establecer una pol´ ıtica que describa la forma de acceder a los recursos. Si no queremos accesos sin autentificar y alguien accede ... Si alguien hace un ataque de denegaci´n de servicio ... o
  39. 39. Pero ... ¿Qu´ es seguridad? e A veces es evidente lo que est´ mal, y no hay que hilar tan fino, a pero ... ¿Un escaneo de puertos es un ataque o no? ¿Hay que responder? ¿C´mo? o
  40. 40. ¿Tiene que ver con la confiabilidad? ‘Reliability’, confiabilidad, ¿no deber´ proporcionar seguridad? ıa La confiabilidad se mide seg´n la robustez de la aplicaci´n u o respecto a los fallos. La definici´n de fallo es an´loga a la definici´n de pol´ o a o ıtica de seguridad.
  41. 41. ¿Tiene que ver con la confiabilidad? Entonces, la seguridad ser´ una parte de la confiabilidad: si se ıa puede violar alguna parte de la pol´ ıtica de seguridad, hay un fallo. Sin embargo... Los problemas de robustez no siempre son problemas de seguridad Lo son m´s frecuentemente de lo que se piensa, de todos a modos. Si dise˜amos pensando en su robustez, seguramente tambi´n n e mejoraremos su seguridad
  42. 42. Malas pr´cticas a Se hacen los programas, se espera a que aparezcan problemas, y se resuelven (si se puede). S´lo se resuelven problemas conocidos por los desarrolladores o No se trabaja ni con el tiempo, ni con la tranquilidad que hace falta. Los parches habitualmente atacan al s´ ıntoma, no al problema Los parches hay que aplicarlos ...
  43. 43. Las metas La seguridad no es una caracter´ ıstica est´tica a 100 % seguro no existe (o es mentira) Mejor ... ¿Qu´ queremos proteger? e ¿Contra qui´n? e ¿Contra qu´? e
  44. 44. Prevenci´n o Normalmente, se presta atenci´n cuando ya es tarde o El tiempo en la red es distinto (velocidad) Los ataques se propagan muy r´pido a Incluso se automatizan
  45. 45. Trazabilidad, auditabilidad Los ataques ocurrir´n a Los contables lo saben (dinero) Estas medidas ayudan a detectar, comprender y demostrar los ataques Es delicado
  46. 46. Vigilancia Auditor´ en tiempo real ıa Se puede hacer a muchos niveles b´squeda de ‘firmas’, patrones ... u ... pero tambi´n aserciones, c´digo a prop´sito. e o o A menudo, con trampas sencillas se puede capturar a un ladr´n, o al menos evitar que haga da˜o. o n
  47. 47. Privacidad y Confidencialidad (Privacidad ←→ Intimidad) Privacidad y confidencialidad son t´rminos muy relacionados e Las empresas deben proteger los datos de sus clientes, incluso de los anunciantes Los gobiernos tambi´n e
  48. 48. Privacidad y Confidencialidad No siempre comprendemos bien las consecuencias de nuestras acciones Los programas deber´ asegurar la privacidad ... ıan ... pero los programas s´lo sirven para hacer el trabajo o Si es posible ... no almacenar secretos
  49. 49. Seguridad multinivel Hay secretos ‘m´s secretos’ que otros a Ni las empresas ni los gobiernos quieren que se sepan algunos datos Adem´s, no todo el mundo tiene que saber lo mismo ... a ... Es complejo
  50. 50. Anonimato Arma de doble filo A veces, hay razones sociales para favorecerlo (SIDA) Pero tambi´n las hay para controlarla (racismo, terrorismo,..) e Junto con la privacidad, es de los temas m´s importantes que a hay que decidir. Global Identifier de Microsoft sirve para saber qu´ copia de e MS Office origin´ un documento o WGA (Windows Genuine Advantage) las ’supercookies’ de Google y Microsoft . . .
  51. 51. Anonimato Carnivore, Echelon, ... ¿qui´n nos garantiza que se usan e ‘adecuadamente’ ? ¿Y las galletitas? ¿Realmente son necesarias? ¿Y si nos las roban? Hay empresas que las ‘coleccionan’ ¿Y si tenemos que hacerlo nosotros? ¿Qu´ pasa si algo va e mal? ¿La comodidad es compatible con la privacidad?
  52. 52. Autentificaci´n o Saber qui´n para saber qu´ puede hacer e e Hasta no hace mucho bastaba con la presencia f´ ısica Internet!!! ¿mibancofavorito.com realmente es MiBancoFavorito? ¿Realmente es un banco? SSL da tranquilidad pero ... ¿qu´ garantiza? e
  53. 53. Autentificaci´n o Nadie mira los datos De muchas formas: mibancofavorito.com → mibacofavorito.com Si vale dinero, hay que tener cuidado. Algunos esquemas suponen anonimato, otros auditor´ ıa. Algunos esquemas est´n orientados a sesiones, otros a a transacciones.
  54. 54. Integridad Seguir teniendo ‘lo mismo’ Precios, cotizaciones, ... ¿y si nos los cambian? La informaci´n digital es muy f´cil de simular o a
  55. 55. Conociendo al enemigo Es bueno conocer los errores frecuentes, sobre todo porque no se suele hablar mucho del tema. Errores de programaci´n (buffers, condiciones de carrera, o n´meros aleatorios) u Pero tambi´n ... e La construcci´n es importante y tambi´n como se usa o e Arquitectura cliente/servidor Ingenier´ social ıa Entradas maliciosas
  56. 56. En resumen Ver lo que va por la red, ponerse en medio Modificar lo que va por la red Simular lo que deber´ ir por la red ıa Reemplazar el flujo de datos Grabar y repetir
  57. 57. Las metas de un proyecto Funcionalidad (resolver el problema) Ergonom´ -usabilidad- (a veces la seguridad interfiere con la ıa comodidad/conveniencia) Eficiencia (a nadie le gusta esperar) El mercado (habitualmente en contra de la simplicidad, y de la gesti´n de riesgos) o Simplicidad (buena para los proyectos, buena para la seguridad)
  58. 58. Bibliograf´ ıa John Viega and Gary McGraw. Building Secure Software. Addison-Wesley Michael Howard, David C. LeBlanc. Writing Secure Code. Microsoft Press. Second Edition. Innocent Code. A security wake-up call for web programmers. Sverre H. Huseby. Wiley.
  59. 59. M´s libros a Software Security. Gary McGraw. Addison-Wesley Software Security Series. OWASP Guide to Building Secure Web Applications (va por la versi´n 3.0) o http: //www.owasp.org/index.php/OWASP_Guide_Project
  60. 60. M´s bibliograf´ a ıa Mark G. Graff, Kenneth R. Van Wyk. Secure Coding: Principles and Practices. O’Reilly & Associates John Viega, Matt Messier. Secure Programming Cookbook for C and C++. O’Reilly & Associates. Gary McGraw, Edward W. Felten. Securing Java: Getting Down to Business with Mobile Code
  61. 61. Bibliograf´ ıa El otro lado. Greg Hoglund, Gary McGraw. Exploiting Software. How to break code. Addison Wesley. Cyrus Peikari, Anton Chuvakin. Security Warrior. O’Reilly. Andrews & Whittaker. How to Break Web Software. Addison Wesley. Tom Gallagher; Bryan Jeffries; Lawrence Landauer. Hunting Security Bugs. Microsoft Press.
  62. 62. M´s bibliograf´ a ıa En la red: Secure Programming for Linux and Unix HOWTO http://www.dwheeler.com/secure-programs/ Security Developer Center Microsoft http://msdn.microsoft.com/security Improving Web Application Security: Threats and Countermeasures http://www.microsoft.com/downloads/details.aspx?familyid= E9C4BFAA-AF88-4AA5-88D4-0DEA898C31B9&displaylang=en Hay mas...
  63. 63. Algunas listas de correo Secure Coding http://www.securecoding.org/list/ WEB APPLICATION SECURITY http://www.securityfocus.com/archive/107 SECPROG http://www.securityfocus.com/archive/98 Web Security http://webappsec.org/lists/ Listas de OWASP http://lists.owasp.org/mailman/listinfo HACK http://mailman.argo.es/listinfo/hacking

×