Seguridad En Ingeniería De Software 2837e

Seguridad en ingeniería de software Contenido Características de seguridad != seguridad en el software ............................................................................ 2 Los siete reinos peligrosos ............................................................................................................................ 3 Validación y representación de entradas ................................................................................................. 4 Abuso de la API ......................................................................................................................................... 4 Características de seguridad ..................................................................................................................... 4 Tiempo y estado........................................................................................................................................ 4 Manejo de errores .................................................................................................................................... 4 Calidad del código ..................................................................................................................................... 5 Encapsulamiento....................................................................................................................................... 5 Entorno ..................................................................................................................................................... 5 Bibliografía .................................................................................................................................................... 5

Características de seguridad != seguridad en el software En ocasiones los programadores piensan en la seguridad, pero muy frecuentemente piensan en términos de las características de seguridad como: criptografía, contraseñas y mecanismos de control de . Como lo dice Michael Howard, un gerente de producto en el equipo de ingeniera de seguridad de Microsoft: "Características de seguridad != seguridad en el software" (Howard & LeBlanc, 2003). Para que un programa sea seguro todas las partes del programa deben ser seguras, no solo los bits que explícitamente se enfocan a la seguridad. En la mayoría de los casos, las fallas de seguridad no están relacionadas con las características de seguridad. Una característica de seguridad puede fallar y comprometer el sistema en muchas formas, pero usualmente existen más formas en las que las características que no están relacionadas con la seguridad pueden fallar y provocar un problema de seguridad. Las características de seguridad se implementan con la idea de que deben funcionar de manera correcta para mantener la seguridad del sistema, pero las características que no están enfocadas a la seguridad frecuentemente no reciben esta consideración, a pesar de que, en ocasiones, son tan críticas como la seguridad del sistema. Los programadores siempre perciben esto de manera incorrecta, y como consecuencia, dejan de pensar en la seguridad cuando se deben enfocar en ella. Considera la siguiente cita errónea de la documentación de WebLogic de BEA: "Debido a que la mayor parte de la seguridad de una aplicación web puede ser implementada por un de sistema, los desarrolladores no deben poner atención a los detalles de seguridad de la aplicación, a menos que se deban tomar consideraciones especiales en el código. Para programar la seguridad a medida dentro de una aplicación, los desarrolladores usando el servidor WebLogic pueden tomar ventaja de la API de BEA para obtener información que será usada por el servidor. La API se encuentra en el paquete weblogic.security." (BEA, 2004). Imagina un ladrón que intenta ingresar a tu casa. Puede comenzar por intentar usar la puerta principal verificando si se encuentra abierta. Si la puerta está cerrada, entonces se ha encontrado con una característica de seguridad. Ahora imagina que las bisagras de la puesta se encuentran en el exterior. El constructor probablemente no pensó en la relación que tienen las bisagras con la seguridad, esto porque las bisagras no son una característica de seguridad, solo se encuentran presentes para que la puerta pueda realizar su requisito de abrir y cerrar. Pero ahora el ladrón no perderá tiempo tratando de forzar la cerradura. Simplemente sacara los tornillos de las bisagras y quitara la puerta. Los constructores pararon de cometer este error hace mucho tiempo, pero en el mundo de la seguridad del software este tipo de errores aun son frecuentes. Considera la lista de las vulnerabilidades de alto perfil descubiertas entre 2002 y 2007 en el software para mostrar imágenes, estas se muestran en la siguiente tabla. En todos los casos, el código que contenía la vulnerabilidad estaba relacionado con el procesamiento de imágenes, no con la seguridad, pero los efectos de estas vulnerabilidades van desde la negación de servicios hasta comprometer el sistema completo.

Tabla 1. Vulnerabilidades de alto perfil descubiertas entre 2002 y 2007 en el software para mostrar imágenes

Fecha Marzo de 2002

Programa zLib

Noviembre de 2002

Internet Explorer

Agosto de 2004

libPNG

Septiembre MS GDI+ de 2004

Julio de 2005

zLib

Diciembre de 2005

Motor de renderizado de gráficos de Microsoft Plataforma de Java 2

Efecto Negación de servicio de que afecta a varios programas, incluyendo aquellos que manejan imágenes PNG. Un archivo PNG puede ser usado para ejecutar código arbitrario cundo se despliega en Internet Explorer. Negación de servicio que afecta a los s de Firefox, Opera, Safari y varios programas más. El código de renderizado JPG permite la ejecución remota de código arbitrario. Afecta a Internet Explorer, Microsoft Office y otros productos de Microsoft. Crea el potencial para la ejecución remota de código. Afecta a mucjos programas incluyendo aquellos que manejan imágenes PNG.

Referencia http://www.securityfocus.com/ bid/6431

http://www.microsott.com/ technet/security/bulletin/ MS02-066.mspx http://www.securityfocus.com/ bid/6431 http://www.microsoft.com/ technet/security/bulletin/ MSO4-028.mspx

http://www.securityfocus.com/ bid/14162

Renderizar archivos WMF permite http://www.microsoft.com/ la ejecución remota de código technet/security/bulletin/ arbitrario. Explotable a través de ms06-001.mspx Internet Explorer. Enero de Renderizar imágenes GIF permite la http://www.sunsolve.sun.com/ 2007 ejecución remota de código search/document.do?assetkey= arbitrario mediante un applet 1-26-102760-1 hostil. En lugar de concentrarnos en las formas de implementar las características de seguridad usando un modulo precargado o mediante un marco de trabajo, debemos identificar y evitar los errores comunes en el código que no están relacionados con la seguridad.

Los siete reinos peligrosos Los siete reinos peligrosos (pernicious kingdoms) es una taxonomía creada por Tsipenyuk, Chess y McGraw (Tsipenyuk, Chess, & McGraw, 2005). El termino reino es usado para agrupar similares. Estos reinos son: 1. 2. 3. 4. 5.

Validación y representación de entradas Abuso de la API Características de seguridad Tiempo y estado Manejo de errores

6. Calidad del código 7. Encapsulamiento 8. * Entorno En realidad son ocho reinos, pero el octavo describe los asuntos de seguridad fuera del código. Esta clasificación sirve para describir los defectos genéricos y los defectos específicos a un contexto.

Validación y representación de entradas Los problemas de validación y representación de entradas son causados por le metacaracteres, codificaciones alternativas y representaciones numéricas. Los problemas de seguridad son resultado de confiar en las entradas. Los problemas relacionados con este reino son los más prevalentes y los más peligrosos de todos los defectos de seguridad en la actualidad.

Abuso de la API Una API es un contracto entre un emisor y un destinatario. La mayoría de las formas de abusar de la API son causadas porque el emisor no cumple con su parte del contrato. Otra forma de abuso es confiar en que una función de búsqueda DNS retornara información confiable. En este caso, el emisor abusa del destinatario asumiendo su comportamiento.

Características de seguridad La seguridad en el software es más que características de seguridad, a pesar de esto, es importante implementar las características de seguridad de forma correcta. Las características de seguridad se refieren a: autenticación, control de , confidencialidad, criptografía y manejo de privilegios. Escribir una contraseña de base de datos dentro del código es un ejemplo de una característica de seguridad mal implementada.

Tiempo y estado Para mantener la cordura, a los programadores les gusta creer que el código se ejecutara en forma ordenada, ininterrumpida y lineal. Los sistemas operativos que corren en sistemas multinúcleo, multiprocesador o en maquinas distribuidas, no siguen esta regla. Los defectos surgen cuando existe una brecha entre lo que el programador piensa y lo que pasa en la realidad. Estos defectos son causados por interacciones inesperadas entre los hilos, procesos, el tiempo y la información. Estas interacciones funcionan mediante el uso de estados compartidos: semáforos, variables, el sistema de archivos y cualquier elemento que puede almacenar información. Los juegos en línea como World of Warcraft frecuentemente contienen vulnerabilidades de tiempo y estado porque permiten que varios s interactúen de forma simultánea (Hoglund & McGraw, 2007).

Manejo de errores Los errores y el manejo de estos representan un tipo de API, pero los errores relacionados con estos son tan comunes que requieren de un reino aparte. Al igual que con el abuso de la API, existen dos formas de introducir errores de seguridad. La primera y la más común es manejar los errores de forma débil o

no manejarlos. La segunda es producir errores que revelan demasiado o que son difíciles de manejar de forma segura.

Calidad del código La poca calidad en el código lleva a comportamientos impredecibles. Desde el punto de vista del , esto se manifiesta como poca usabilidad. Para un atacante esto representa la oportunidad de sobrecargar el sistema de formas no previstas. Entrar a un ciclo infinito o hacer referencia a un puntero nulo puede llevar un ataque de negación de servicio, pero también crea las condiciones necesarias para que el atacante tome ventaja usando el código mal escrito. El buen código y la buena seguridad están íntimamente relacionados.

Encapsulamiento El encapsulamiento es tener fuertes fronteras. En un navegador web esto puede significar que el código móvil no pueda ser usado por otro código móvil. En el servidor esto pude significar la diferenciación entre la información validada y la que no lo está, o entre la información que puede ver el y la que no.

Entorno Este reino incluye todo lo que esta fuera del código pero que es crucial para la seguridad del producto. Los archivos de configuración que gobiernan el comportamiento del programa y las banderas usadas para construir el programa son dos ejemplos de la influencia del entorno en la seguridad del software.

Bibliografía BEA. (2004). WebLogic Server documentation. USA: BEA. Chess, B., & West, J. (2007). Secure Programming with Static Analysis. USA: Addison-Wesley Professional. Dowd, M., McDonald, J., & Schuh, J. (2006). The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities. USA: Addison-Wesley Professional. Hoglund, G., & McGraw, G. (2007). Exploiting Online Games: Cheating Massively Distributed Systems. USA: Addison-Wesley Professional. Howard, M., & LeBlanc, D. (2003). Writing Secure Code. USA: Microsoft Press. Tsipenyuk, Chess, & McGraw. (2005). Seven Pernicious Kingdoms: A Taxonomy of Software Security Errors. USA: Fortify Software.