¿Quieres programar de forma segura? Lenguajes que debes evitar

¿Quieres programar de forma segura? Lenguajes que debes evitar

Rubén Velasco

Hoy en día vivimos en el mundo de la inseguridad y la falta de privacidad. Desde los propios sistemas operativos, hasta los programas que usamos a diario, es muy común encontrarnos con todo tipo de vulnerabilidades que pueden poner en peligro nuestra seguridad. Sin embargo, ¿de quién es la culpa de que haya fallos de seguridad? ¿de los desarrolladores? ¿de los lenguajes de programación? ¿hay lenguajes de programación seguros e inseguros? ¿o en realidad ambas partes tienen la culpa?

Los sistemas operativos y los programas de hoy en día son proyectos realmente complejos. El más pequeño fallo o despiste en una de las cientos de librerías puede hacer que nuestro programa ponga en peligro a los usuarios. Todos los lenguajes de programación son, por defecto, seguros. Si los usamos bien, no tienen por qué poner en peligro a los usuarios. Aunque, ahora bien, hay lenguajes mucho más propensos a fallos (por despistes, complejidad o falta de medidas de seguridad) que pueden dar lugar a vulnerabilidades de todo tipo.

open source vulnerabilities

Lenguajes de programación más seguros

De todos los lenguajes de programación más utilizados, el que menos vulnerabilidades tiene es Ruby. Este lenguaje de programación solo ha estado afectado por un 5% de las vulnerabilidades. Además, a grandes rasgos, es uno de los lenguajes más seguros y robustos, ya que aunque se han reportado varias vulnerabilidades en él, la única realmente preocupante es la posibilidad de realizar ataques XSS. Si hubiera que recomendar el lenguaje de programación más seguro, este sería el idóneo para el título.

C++ es otro de los lenguajes de programación con menos vulnerabilidades que podemos encontrar, con tan solo un 6% de código vulnerable. Sin embargo, no es precisamente uno de los más depurados, ya que tiene una gran cantidad de problemas de corrupción de memoria y errores de búfer que pueden dar lugar a ataques informáticos más complejos.

Continuando la lista de lenguajes de programación seguros con menos vulnerabilidades llegamos a Python. En el pasado, este lenguaje fue uno de los peores en cuanto a seguridad. Sin embargo, en los últimos años ha mejorado mucho y ha abordado la mayoría de los problemas que le afectaron en el pasado. Eso sí, sigue teniendo las vulnerabilidades más críticas que podemos encontrar hoy en día, como faltas de validación de entrada, escalada de privilegios, fuga de información y XSS. Si sabemos programar en Python podemos tener un programa robusto. Pero si programamos mal tendremos un coladero, literalmente.

Y también tiene especial mención JavaScript. Este también se utiliza mucho en desarrollo web y solo esconde el 11% de las vulnerabilidades. Entre sus principales debilidades se encuentran los problemas criptográficos, que nos obligarán a usar APIs de terceros para solucionarlos.

Lenguajes con más vulnerabilidades

Por otro lado, entre los lenguajes de programación más vulnerables, el primero que nos vamos a encontrar es C. Y esto es obvio, ya que es uno de los lenguajes de programación en el que hay más código escrito (especialmente código antiguo), por lo que la probabilidad de que se descubran vulnerabilidades en este código es muy elevada. Del total de vulnerabilidades encontradas, el 47% se encuentra en código escrito en este lenguaje de programación. Sin embargo, fallos como tal propios del lenguaje solo se han encontrado dos, un error de búfer y distintos problemas de validación.

PHP es uno de los lenguajes más utilizados en programación web (backend) y, por lo tanto, uno de los más llamativos para los piratas informáticos. Este es el segundo lenguaje de programación con más vulnerabilidades (17% del total), y lo que más llama la atención es que este lenguaje es el único que tiene vulnerabilidades críticas como la SQL Injection, y al que también se le puede explotar a través de XSS. Dos vulnerabilidades muy explotadas en toda la red y difíciles de erradicar.

Y, por supuesto, no podíamos terminar sin hablar de Java. El lenguaje de programación multiplataforma tan utilizado hace unos años también es uno de los que más vulnerabilidades esconden en su interior, debido a su complejidad. El 12% de las vulnerabilidades se encuentran en este lenguaje de programación que, aunque ha perdido bastante popularidad últimamente, sigue siendo uno de los pilares fundamentales de Android.

Reutilizar código: ¿ventaja o riesgo?

En la actualidad es posible encontrar una gran cantidad de código abierto en plataformas como, por ejemplo, GitHub. Este código, según la licencia que tenga, se puede reutilizar libremente en otros tipos de proyectos, lo que puede llegar a ahorrarnos una gran cantidad de tiempo al dar forma a nuestros programas. Sin embargo, la reutilización de código esconde uno de los mayores problemas del OpenSource: las vulnerabilidades.

Es muy común que todo tipo de desarrolladores, incluso las grandes empresas como Microsoft o Google, se aprovechen de librerías abiertas para llevar ciertas funciones y características a los usuarios. Hasta aquí todo bien, ya que, además, brinda un poco de transparencia a los proyectos tan opacos que suelen crear estas empresas. Sin embargo, debemos tener en cuenta un handicap muy importante: una vulnerabilidad en una librería de código abierto pondrá automáticamente en peligro todos los proyectos que la utilicen.

Ya hemos visto grandes vulnerabilidades (como la de OpenSSL) que ha puesto en jaque la seguridad de miles de programas y plataformas en todo el mundo. Y, además, cuando se descubre una vulnerabilidad de este tipo es necesario, por un lado, que el desarrollador del proyecto original actualice su librería, y por otro lado que los desarrolladores de los programas vulnerables incluyan la nueva versión en su programa a través de una actualización.

La reutilización de código es una de las características de los programas y sistemas modernos. Pero nunca debemos confiarnos, ya que la probabilidad de que aparezca una vulnerabilidad en el código que hemos utilizado es mucho más alta que si hubiéramos creado nosotros mismos el código.