cerrar-sesion editar-perfil marker video calendario monitor periodico fax rss twitter facebook google-plus linkedin alarma circulo-derecha abajo derecha izquierda mover-vertical candado usuario email lupa exito mapa email2 telefono etiqueta

3002007050405. Codificar de forma segura

Escrito por Redacción en Artículos
no hay comentarios Haz tu comentario
Imagen de logotipo de facebook Imagen de logotipo de Twitter Imagen de Logotipo de Google+ Imagen de logotipo de Linkedin

Hace ya mucho tiempo pude escuchar de los labios de un experto programador que a�?la programaciA?n no es simplemente lograr que el cA?digo haga una serie de tareas, sino conseguir que se contemplen todas las eventuales sucesos anA?malos en su ejecuciA?na�?. Una frase que refleja que la parte mA?s complicada de un programa no es la misiA?n principal, donde un programador razonablemente eficaz es capaz de dirigir su esfuerzo, sino en evitar las mA?ltiples calamidades que pueden ocurrir de forma inesperada. O al menos de manera no prevista oficialmente en el diseA�o del programa.

Control de errores

Desde luego el control de errores es uno de los temas mA?s tA�picos dentro de esta categorA�a de gestionar los sucesos anA?malos de un programa. Los entornos de desarrollo y librerA�as bA?sicas de soporte ya contemplan una gestiA?n bA?sica de este tipo de errores. AsA� que en muchos casos basta activar la librerA�a o el mA?dulo de control de errores.

Evitar que en un cA?lculo no haya una divisiA?n por cero es sA?lo de los mA?ltiples problemas en los que puede caer un programa. Una novatada por la que seguramente muchos programadores novatos han pasado, con gran regocijo de los programadores senior. El proceso de aprendizaje para sortear estos errores elementales no es complicado, pero a veces las prisas nos traicionan y tampoco resulta extraA�o que aparezcan.

Dimensionar de forma escasa el buffer que debe recibir los datos, usar un tipo diferente de datos, o no comprobar que se trabaja con el tipo adecuado, son un siguiente nivel de errores que las herramientas de cierto nivel y los entornos de programaciA?n han ido relegando al olvido. Pero no estA? de mA?s hacer pruebas de cA?mo se comporta el programa cuando en lugar de recibir en el campo de unidades una cifra entre 1 y la cantidad mA?xima del almacA�n algA?n usuario se empeA�a en insertar un gran nA?mero de cifras. O incluso letras donde se esperaban nA?meros.

Con cierto nivel de experiencia, y, sobre todo, buenas prA?cticas de programaciA?n, un codificador es capaz de evitar gran parte de estas trampas que pueden sembrar el cA?digo y convertirlo en un quebradero de cabeza para el jefe de proyecto. La mayor parte de las empresas de desarrollo cuentan con normas y tratados de buenas prA?cticas que son la lectura obligada de cualquier nuevo miembro del equipo de trabajo.

Pero cuando un proyecto se compone del esfuerzo de mA?ltiples programadores, de miles o millones de lA�neas de cA?digo y de mA?ltiples bloques cada uno encargado de una parte de las tareas, lograr un funcionamiento correcto del conjunto parece tarea imposible. O al menos que requiere un esfuerzo titA?nico. Lo que lleva asociado un elevado tiempo de trabajo y un coste asociado importante. Factores todos ellos que no favorecen un proyecto comercial de desarrollo.

Hackers

Para empeorar las cosas ya no se trata actualmente de errores encontrados casualmente. Los ataques contra los usuarios, los servidores y las aplicaciones se han profesionalizado. En busca de un beneficio econA?mico, los hacker modernos buscan sistemA?ticamente cualquier hueco en las aplicaciones para tomar control de un sistema vulnerable. Por ello, el cA?digo debe ser creado con las mayores garantA�as.

Hay un buen nA?mero de vulnerabilidades y errores mA?s o menos conocidos. Que suelen tener su correspondiente parche o soluciA?n no mucho despuA�s. En algunos casos se trata de fallos de tipo comA?n en un programa, como buffer overflow, inyecciA?n SQL o similares. AsA� que tambiA�n es conocida la forma de atacar un sistema que contenga estos fallos.

Un atacante puede buscar metA?dicamente los errores tA�picos de una aplicaciA?n, sobre todo de una de tipo Web, para localizar los puntos dA�biles y lograr ya sea acceder al sistema o simplemente interferir su correcto funcionamiento. AsA� que la mejor manera es evitar que esto ocurra es evitar los fallos a�?conocidosa�? para evitar la debilidad del sistema.

Pero esto no impide la existencia de otros fallos no conocidos inicialmente, que puedan aparecer con posterioridad. Si el remedio para los primeros, y en buena medida para los segundos, es una buena prA?ctica de programaciA?n, la mejor defensa para vulnerabilidades desconocidas es la mantener informaciA?n actualizada y tener capacidad para desplegar la soluciA?n sobre los equipos instalados.

ActualizaciA?n

Los nuevos proyectos se construyen usando herramientas de alto nivel que compilan el programa fuente y aA�aden toda una serie de bloques o mA?dulos para crear el ejecutable final. Esto significa que hay mA?s cosas que el propio cA?digo fuente en el cA?digo resultante. Los grandes fabricantes de software, asA� como de herramientas de desarrollo comprueban minuciosamente sus productos. Pero esto no es garantA�a de que no haya problemas en alguno de los mA?ltiples elementos que estA?n involucrados en el producto final.

Las herramientas de programaciA?n tienen dependencias de librerA�as y formularios, tanto del entorno de programaciA?n como del sistema operativo sobre el cual trabajan, en los cuales puedan aparecer vulnerabilidades o errores de cA?digo que hagan a la aplicaciA?n derivada igualmente vulnerable. Eso hace que sea necesario contar tanto con las A?ltimas actualizaciones a la hora de elaborar el programa final, como con las debidas actualizaciones sobre los equipos en los que se ha desplegado la aplicaciA?n.

La mayor complicaciA?n en este campo es llevar el control de revisiones de todos los elementos de componen/compusieron los diversos mA?dulos y librearA�as necesarias para el producto final. Junto a esto, hay que contar con mecanismos para desplegar la aplicaciA?n en un elevado nA?mero de equipos dispersos por mA?ltiples despachos, edificios o incluso poblaciones.


AsA� que ademA?s de las herramientas para creaciA?n de programas se necesita contar con mecanismos para desplegarlos y asA� poder corregir rA?pidamente cualquier fallo o vulnerabilidad existente.

DocumentaciA?n

AdemA?s de crear cA?digo fiable y seguro en cuanto a ejecuciA?n, otros detalles merecen igualmente atenciA?n. AsA�, la documentaciA?n y sistema de ayuda son igualmente importantes. Y muy normalmente A�stos utilizan el formato el PDF como formato de fichero. A pesar de su aparente inocuidad, los archivos PDF estA?n preparados para ejecutar cA?digo, lo que les convierte en un peligro potencial e incluso real.

Un peligro ademA?s conocido y que, descubierto a finales de septiembre, afecta a varias versiones de Acrobat Reader en versiones 8.1 y anteriores, asA� como Adobe Acrobat Standard, Professional y Elements 8.1 junto con sus correspondiente versiones previas, y Adobe Acrobat 3D. El problema es conocido desde finales de septiembre y todavA�a no resuelto por Adobe a la hora de escribir estas lA�neas.

Para paliar el problema Adobe ha indicado un complejo sistema manual para impedir la activaciA?n de un archivo modificado de forma maliciosa mientras crea una soluciA?n permanente al tema. Como soluciA?n parcial y temporal, Adobe, como se indica en http://www.adobe.com/support/security/advisories/apsa07-04.html, un parche complejo y que implica la modificaciA?n del registro para desactivar la opciA?n de envA�o por correo (mailto). Pero se trata de una soluciA?n un tanto enrevesada y no apta para todo el mundo. Y ya se sabe que las modificaciones del registro de Windows son siempre peligrosas.

El fallo permitirA�a a un hacker crear un archivo PDF modificado con capacidad para tomar el control de sistem que tengan el sistema operativo Windows XP con SP2 con Internet Explorer 7 instalado en A�l. Para que el ataque se inicie basta que un usuario abra el archivo PDF modificado, o incluso visite una pA?gina que lo contenga, y, de forma totalmente invisible y silenciosa, el sistema resulta comprometido.

La gravedad del fallo proviene de varios factores. Uno es el gran desconocimiento del problema. Mientras que de otros formatos de archivos es conocido el peligro (macros de Word, formato grA?fico JPG, etc), el formato PDF pasaba hasta ahora por un sistema fiable, universal y seguro. Por ora parte, el formato PDF resulta muy extendido como medio de documentaciA?n por todo tipo de fabricantes, desde ordenadores a perifA�ricos y reproductores MP3, lo que multiplica las posibles fuentes de procedencia.

Por A?ltimo, el formato PDF cuenta con soporte directo en los principales navegadores. Lo que significa que puede abrirse de forma muy directa en una pA?gina Web. Si se inserta un PDF modificado en una pA?gina, y se activa la descarga o la vista previa automA?tica, la simple visita al sitio asaltado desencadena la silenciosa infecciA?n.

Herramientas de verificaciA?n

Nunca es tarde para iniciar el reforzamiento de la seguridad del cA?digo. Como toda iniciativa, esto puede suponer un desembolso inicial de cierta importancia. Pero que pronto se revelarA? rentable gracias al ahorro en las fases de pruebas y, sobre todo, en las de verificaciA?n de un proyecto de desarrollo.

Pero hay que contar con el sobre-proceso inicial. SegA?n los expertos, la adopciA?n de prA?cticas con enfoque a crear cA?digo mA?s seguro en el proceso de desarrollo puede aA�adir como un tercio de tiempo adicional. Gran parte de este tiempo extra se destina a educar y reconvertir a los desarrolladores sobre cA?mo reconocer y prevenir las vulnerabilidades de seguridad, como overflow de un buffer, scripting de sitio cruzado (cross-site scripting) o inyecciA?n SQL.

Las herramientas de evaluaciA?n de suponen una ayuda inestimable para verificar el cA?digo escrito por empresas off-shore o por colaboradores externos que quizA?s no cuentan con la misma formaciA?n en seguridad de cA?digo que se ya se ha impuesto en el desarrollador. Y tambiA�n para revisar el cA?digo de las aplicaciones previamente creadas en la empresa.

Desde luego esto supone un cambio en la mentalidad, ya que no es raro que este tipo de comprobaciones se realizaran de forma externa, o mediante auditorias en el cliente una vez el proyecto en al fase. Aunque no hay que descartar el empleo de auditores externos para realizar un bA?squeda de vulnerabilidades, verificando un anA?lisis del cA?digo y test de penetraciA?n.

La respuesta de los desarrolladores que ya han implementado este tipo de prA?cticas resulta reveladora. Aunque todos consideran el tiempo adicional en las fases iniciales de codificaciA?n, debido a la necesidad de validar cada rutina de cara a seguridad, tambiA�n destacan las ventajas. Y es que pronto aprenden a hacer mejor su trabajo la siguiente vez. Lo cual se acaba convirtiendo en una rutina que contribuye a mejorar la calidad del cA?digo generado.

El trabajo adicional depende del bagaje previo de cada desarrollador, asA� como de cuA?ntas veces ha estado involucrado con estas prA?cticas de codificaciA?n segura. A medida que un desarrollador ve los registros de un anA?lisis de seguridad en el cA?digo que ha escrito, o supervisado, aprende a evitar errores y realizar su tarea de forma mA?s eficaz en la siguiente ocasiA?n.

Microsoft promueve el cA?digo seguro

Ha llovido mucho desde que Bill Gates lanzA?, a mediados de enero de 2002, su famoso memorando “Trustworthy Computing” para impulsar que Microsoft se convirtiera en abanderado del cA?digo seguro. Cerca de seis aA�os mA?s tarde la cuestiA?n sigue abierta, aunque hay que reconocer que han logrado grandes progresos gracia a ese enfoque en seguridad.


En Visual Studio 2005 Microsoft integrA? un par de herramientas de anA?lisis estA?tico, FxCop y PREfast, dentro del conjunto de herramientas denominado Managed Code Analysis and C/C++ Code Analysis, segA?n indicA? S. Somasegar, vicepresidente corporativo de la divisiA?n de desarrollo de Microsoft en un reciente mensaje, el 4 de octubre, en su blog.

Para el futuro Visual Studio 2008, el equipo de anA?lisis de cA?digo de Microsoft estA? aA�adiendo nuevas funcionalidades, incluyendo Code Metrics, una nueva herramienta que permite realizar tanto una revisiA?n general de calidad de cA?digo de la aplicaciA?n como un anA?lisis en profundidad. Para Visual Studio 2008, Code Metrics incluirA? cinco tipos de mA�tricas: Cyclomatic Complexity, Depth of Inheritance, Class Coupling, Lines of Code y Maintainability Index.

Otras mejoras incluirA?n Code Analysis Policy que proporciona la habilidad para asegurar que se ejecuta el anA?lisis de cA?digo antes de cada proceso de prueba. El anA?lisis de cA?digo de Visual Studio tambiA�n aA�adirA? diversas mejoras en el anA?lisis como: soporte para analizar mA�todos anA?nimos y expresiones lambda, inclusiA?n de reglas adicionales sobre seguridad, mejor soporte C++/CLI y el Compact Framework, y otras varias. Todo ello con un incremento del rendimiento del doble de velocidad y un consumo de la mitad de memoria que en el equivalente en Visual Studio 2005.

Herramientas de control de cA?digo

Sin duda por mA?s que se empleen buenas prA?cticas, si se desea aumentar el nivel de seguridad del cA?digo hay que recurrir a herramientas especA�ficas que tengan capacidad para analizar el cA?digo, tanto el cA?digo fuente como el binario resultante, en busca de vulnerabilidades o problemas. De esta manera se evitan problemas antes de lanzar un producto comercial.

Las principales firmas de desarrollo emplean al menos uno, cuando no varios, de los productos que aseguran la minimizaciA?n de riesgos en el cA?digo. Entre las herramientas de este tipo cabe citar:
– Fortify Source Code AnA?lisis, Fortify SCA (http://www.fortifysoftware.com), es la principal herramienta en este campo y tiene una sA?lida fama debida a sus clientes, entre los que se encuentran grandes firmas como Adobe, Oracle, Bank of America, Symantec, y Wells Fargo. El producto analiza el cA?digo tanto desde un punto de vista meramente de seguridad como de oportunidad de explotar debilidades, vulnerabilidades El producto se ejecuta sobre Windows, Linux, Solaris, HP UX, IBM AIX, y Mac OS X. Fortify es patrocinador de FindBugs una herramienta de fuente abierta que analiza fallos en Java, pero es bA?sicamente una herramienta profesional de alto coste.
– Coverity (www.coverity.com), en ocasiones se define como una herramienta de calidad de software, aunque de forma similar al producto anterior es capaz de verificar problemas de memoria en programas de C y C++. Otra de sus especialidades es la comprobaciA?n de diversos problemas relacionados con formato de datos o con uso indebido de memoria, como buffer overflow o escritura fuera de los buffers. Coverity tambiA�n realiza auditorA�as diarias de software de fuente abierta, como Linux, Apache, MySQL, Mozzilla, etc, y entre sus clientes se mencionan empresas como Cisco, McAfee, EMC, Juniper, Pandasecurity, NTT y la NASA.
– Klocwork (www.klocwork.com), una herramienta que cubre un entorno similar a Fortify, pero con menor alcance, aunque su interface de usuario ofrece algunas interesantes prestaciones de las que carece su motor de revisiA?n. Este producto se etiqueta habitualmente como una herramienta de calidad de software, pero cuenta con interesantes informes y capacidades de ingenierA�a inversa. Klocwork K7 se integra con el IDE de Eclipse IDE, y hay plug-ins para Windriver Workbench, Visual Studio e IBM Rational Application Developer for Websphere Software. Entre sus clientes mA?s conocidos, HP, Avaya, LG, Trens Micro o Motorola.
– Ounce (www.ouncelans.com) cuenta con su producto estrella praxis que es un software orientado a permitir que los desarrolladores identifiquen, prioricen y eliminen los eventuales riesgos provocados por las vulnerabilidades de seguridad del software. Ounce analiza el cA?digo fuente de la aplicaciA?n y suministra un completo anA?lisis de potenciales problemas.
– Reasoning (www.reasoning.com) combina la mediciA?n de riesgos de seguridad y la comparaciA?n con otras mA?ltiples aplicaciones analizadas previamente. Su mA�todo propietario denominado DMA, Discovery Mapping Analytics, realize un barrido completo del cA?digo. El Reliability Inspection Services de Reasoning analiza codigo fuente de Java, C, and C++ en busca de defectos que no ha sido percibidos, asA� como las condiciones en las que ocurren.
– Purify (http://www-306.ibm.com/software/awdtools/purify/), es una soluciA?n disponible para Linux, Unix y Windows. Su especialidad es la detecciA?n de corrupciA?n de memoria, asA� como otros problemas relativos el empleo de la memoria, junto con una elevada velocidad de depuraciA?n y diagnA?stico de problemas y una elevada escalabilidad. El producto analiza Java, C/C++, Visual Basic y las diversas variantes del lenguaje .NET, incluyendo C# y VB.NET, asA� como C/C++ para Linux y UNIX.
– PolySpace (www.polyspace.com), es una herramienta con un propA?sito algo distinto a los anteriores, ya que intenta descubrir matemA?ticamente errores en el cA?digo ejecutable a la vez que usa anA?lisis estA?tico para lograrlo. Este producto realiza un buen trabajo con proyectos pequeA�os, pero, debido a la complejidad y minuciosidad de su anA?lisis es algo lento. PolySpace necesita evaluar una aplicaciA?n completa para realizar un buen anA?lisis.
– WebInspect, http://www.spidynamics.com/products/webinspect/index.html, es un producto de SPI Dynamics que permite revisar y detectar vulnerabilidades en aplicaciones Web. Actualmente en su version 7, WebInspect es capaz de revisar cA?digo de aplicaciones emergentes orientados a la Web 2.0, con empleo de tecnologA�as como AJAX, SOAP, SOA, JavaScript y Flash.

Un enfoque algo distinto es el adoptado por la Code Assurance Security Platform de Veracode ya que se trata de un servicio en el cual el cliente descarga el cA?digo a los servidores de esta empresa. AllA� el cA?digo es analizado usando la herramienta propietaria de Veracode. Como un dA�a despuA�s, el cliente obtiene un completo informe con las vulnerabilidades encontradas en el cA?digo.

El cliente podrA? entonces obtener mA?s informaciA?n a travA�s del enlace asociado a cada fallo encontrado en el cA?digo y ver asA� la secciA?n explicativa. Veracode funciona como un servicio bajo demanda, con un modelo basado en suscripciA?n, una de cuyas caracterA�sticas mA?s notables es que no analiza simplemente el cA?digo fuente, sino tambiA�n el binario, con los que es capaz de detectar fallos en el cA?digo final, asociados no sA?lo al cA?digo fuente, sino al mA�todo para generar el ejecutable.

Dada la complejidad creciente de los desarrollos, junto con la importancia de los programas en todos los A?mbitos de nuestra vida, se necesita un uso creciente de herramientas y procesos de comprobaciA?n de cA?digo. 

Etiquetas

Noticias relacionadas

Comentarios

No hay comentarios.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Debes haber iniciado sesión para comentar una noticia.