¿Cuáles son los lenguajes de programación más seguros?
Un informe de Veracode concluye que algunos lenguajes de programación son más susceptibles que otros a ciertas vulnerabilidades, como los ataques de inyección de código SQL.
Aunque los fallos de seguridad afectan a aplicaciones escritas con cualquier lenguaje de programación, un informe titulado “State of Software Security” que acaba de publicar Veracode concluye que las apps creadas con ciertas tecnologías son más propensas a sufrir vulnerabilidades que el resto.
O, en todo caso, que los desarrolladores que los utilizan son más propensos a cometer errores.
El problema radica en que algunos lenguajes como C/C++ “no son type safe“, según comenta Chris Eng, vicepresidente de investigación de Veracode. El término “Type safe significa que es el lenguaje en sí mismo, en vez del programador, el que comprueba si un objeto de datos es un entero o una cadena, además de la cantidad de espacio necesario para almacenar el objeto. Si no hay suficiente espacio de almacenamiento, acabarás sufriendo un problema de desbordamiento”.
“En C/C++, el programador tiene que llevar un registro del tipo y el espacio sin la ayuda del lenguaje o del compilador, lo que da lugar a errores en el software”, continúa explicando Eng. Por su parte, “lenguajes como .Net sí son type safe, por lo que el desarrollador obtiene una ocurrencia mucho más baja de fallos por desbordamiento”.
Traducido a porcentajes y en base a los resultados de la investigación realizada por Veracode, sólo el 1% de las aplicaciones .NET se ven afectadas por este tipo de complicaciones. Sin embargo, el número asciende hasta el 48% en C/C++ para las primeras versiones de las aplicaciones.
En el caso de las vulnerabilidades por inyección de código SQL, las cifras se sitúan en el 31% de las aplicaciones Java, en el 27% de las aplicaciones PHP y en el 72% de las aplicaciones ColdFusion.
¿Para qué sirve toda esta información? Para estar más alerta. “Las organizaciones pueden estimar el impacto de implementar o modificar las políticas de seguridad de sus aplicaciones” y prevenir quebraderos de cabeza. “Tomemos como ejemplo la situación de un equipo de seguridad que redacta una política encaminada a eliminar fallos de inyección SQL y un equipo de desarrollo que escribe su aplicación en Java”, propone Veracode. “Los porcentajes nos dicen que hay una posibilidad del 31% de que la aplicación tenga un fallo de inyección SQL. Y los datos de prevalencia de vulnerabilidad dicen que si la aplicación tiene inyección SQL, lo más probable es que sólo el 3% de las vulnerabilidades encontradas sean de ese tipo”.
Eso sí, las mejoras de diseño que se implementen a partir de ahí pueden mejorar la seguridad, “pero también deben dar a los desarrolladores flexibilidad para innovar”, advierte Eg. “Es por eso que los desarrolladores siempre asumirán parte de la responsabilidad de crear código más o menos robusto“.
“La principal preocupación de las organizaciones de desarrollo es la creación de software que cumpla con el calendario de plazos fijado”, señala el directivo, como uno de los grandes problemas. “Éstas no se centran en metas de seguridad, sino que sus prioridades están atadas al tiempo de comercialización, lo que significa que las preocupaciones de seguridad suelen ser recortadas”.
Realizar pruebas de estabilidad internas en los propios equipos de desarrollo y tener un plan de acción más sencillo que permita crear e implementar soluciones son dos mecanismos que podrían ayudar a reducir el riesgo.
