¿Qué tan seguro es Java en comparación con otros lenguajes?

Al igual que con otros aspectos de la ciberseguridad, el nivel de seguridad del lenguaje de programación depende de lo que entendamos por "seguro". Es cierto que Java tiene menos vulnerabilidades identificadas que otros lenguajes de uso común. También es cierto que algunos lenguajes más nuevos parecen más seguros que Java, al menos a primera vista.

Muchos de los agujeros de seguridad que se han encontrado en Java son el resultado de su popularidad. El uso generalizado significa que miles de cazadores de errores se dedican a encontrar vulnerabilidades del lenguaje Java, lo que le da a Java una "ventaja" injusta en este campo. Del mismo modo, la seguridad implícita de algunos lenguajes más nuevos, como Ruby, podría reflejar su uso de nicho más que su integridad.  

[También en JavaWorld: hay algunas señales de que los desarrolladores de Java están mejorando en seguridad]. 

En este artículo, veremos cómo se clasifican los lenguajes de programación más utilizados en términos de seguridad. Explicaré algunos factores que hacen que un idioma sea menos seguro que otro y por qué las vulnerabilidades identificadas han aumentado tanto en los últimos años. Finalmente, sugeriré algunas formas en que los desarrolladores de Java pueden reducir las vulnerabilidades en el código.  

En pocas palabras: desde una perspectiva de seguridad, las vulnerabilidades que conocemos son mejores que las que no conocemos. 

¿Qué tan seguro es Java?

La investigación reciente sobre las vulnerabilidades de los lenguajes de programación más utilizados proviene de WhiteSource, una plataforma de seguridad de código abierto y cumplimiento de licencias. WhiteSource analizó siete de los lenguajes de programación de código abierto más populares: C, Java, JavaScript, Python, Ruby, PHP y C ++. Luego, los analistas utilizaron una variedad de fuentes para clasificar los idiomas según la cantidad de vulnerabilidades identificadas.

¿Por qué código abierto?

La decisión de clasificar los lenguajes de código abierto no es casual. Muchos lenguajes propietarios, incluidas las implementaciones propietarias de lenguajes de código abierto, son mucho menos transparentes cuando se trata de vulnerabilidades. No tiene sentido comercial que una empresa privada publique fallas de seguridad en su producto, por lo que permanecemos en gran parte en la oscuridad sobre el nivel de vulnerabilidad de esos idiomas. Los defectos que conocemos son mucho más manejables que los que no conocemos.

Según el estudio de WhiteSource, el lenguaje de programación más vulnerable fue C, con el 47% de todas las vulnerabilidades reportadas . Esa clasificación no sorprenderá a los programadores experimentados, pero otros resultados sí. PHP quedó en un distante segundo lugar, con un 17%, seguido de Java con un 12%, y JavaScript completando los cuatro primeros con un 11%. Después de estos "líderes" estaban Python, C ++ y Ruby. 

Comprender la seguridad del lenguaje de programación

A continuación, deberíamos preguntarnos por qué algunos lenguajes de programación son más vulnerables que otros. Según la investigación que he citado, podría concluir que C representa una enorme amenaza a la seguridad. Pero tenga en cuenta que C se ha utilizado durante mucho más tiempo que cualquier otro idioma de la lista. Como dice Stephen Turner, escribiendo en el Journal of Technology Research, "los lenguajes de programación son como la genética, en el sentido de que hay algunos antepasados ​​con rasgos comunes que han proliferado". 

Como el lenguaje más antiguo de la lista, C se desarrolló en un entorno de amenazas completamente diferente al de lenguajes relativamente nuevos como Java y Ruby. Como señala WhiteSource, la edad relativa de C significa que tiene un volumen correspondientemente mayor de código escrito. C también es uno de los lenguajes utilizados para las principales infraestructuras como OpenSSL y el kernel de Linux. Esa combinación de volumen y centralidad puede conducir a un mayor número de vulnerabilidades conocidas de código abierto.

Aunque Java funciona bien en este análisis, los autores destacan dos tipos de vulnerabilidad que afectan especialmente a Java. Primero, señalan que US-CERT nos ha advertido durante mucho tiempo sobre la vulnerabilidad de Java a los ataques de inyección de registros, principalmente a través de navegadores web. Estos ataques pueden evitarse mediante la validación o autenticación de la entrada enviada, pero los desarrolladores a menudo son reticentes a validar la entrada a fondo por temor a que esto pueda hacer que sus aplicaciones sean menos fáciles de usar. 

En segundo lugar, Java es particularmente vulnerable a las vulnerabilidades de confianza que siguen a las vulnerabilidades de control de acceso. Aunque los procesos de certificación han mejorado desde 2013, muchos desarrolladores confían en certificados de autoridades que son menos confiables. Es posible obtener un certificado que sea menos estricto de lo que debería ser. US-CERT, citado en el Journal of Technology Research, advierte sobre esta puerta abierta para atacantes remotos que ejecutan código arbitrario.

La vulnerabilidad relativamente baja de Java ofrece un contraste interesante con C. Java se desarrolló mucho después de C, en un entorno donde la conciencia de las amenazas era mucho mayor, por lo que no sorprende que Java sea mucho más seguro. Del mismo modo, aunque Ruby parece ser más seguro que Java, esto podría explicarse por la relativa juventud del lenguaje y su aplicación de nicho.

Las vulnerabilidades de seguridad van en aumento, una especie de

WhiteSource informa un "aumento sustancial en el número de vulnerabilidades de seguridad de código abierto conocidas en todos los idiomas durante los últimos dos años". Aunque el número total de vulnerabilidades en Java ha disminuido constantemente desde 2015, el pico más reciente en el número de vulnerabilidades requiere una explicación. Podemos atribuir este aumento a dos factores.  

Primero, están las recompensas por errores, una tendencia relativamente nueva en la que miles de profesionales de la tecnología seleccionan un idioma para encontrar vulnerabilidades. Estos explican al menos parte del aumento de las vulnerabilidades de seguridad de código abierto. Además, generalmente se asume que los cazadores de amenazas escanean todos los idiomas por igual, pero eso no es cierto. Como uno de los lenguajes más utilizados en el desarrollo web, Java es un objetivo importante para los cazadores de amenazas. En este contexto, la clasificación de Java en tercer lugar para vulnerabilidades conocidas comienza a parecer bastante baja.

Los sistemas de software también son un orden de magnitud más complicados que hace 10 años, lo que es otro factor importante en el creciente número de vulnerabilidades encontradas en Java y otros lenguajes. En un mundo donde las aplicaciones para teléfonos inteligentes pueden ser una fuente de infección, y donde todas las empresas deben tener un sitio web habilitado para JavaScript, no sorprende que la cantidad de vulnerabilidades del sitio web haya aumentado exponencialmente. Agregue a esto la escasez a largo plazo de profesionales de la ciberseguridad, y las cosas comienzan a verse sombrías para el futuro de la ciberseguridad. 

Cómo evitar las vulnerabilidades de seguridad de Java

Leer la investigación sobre vulnerabilidades de seguridad puede hacer que su corazón lata más rápido, pero no temas: los desarrolladores de Java están en una posición sólida cuando se trata de seguridad de aplicaciones. Con miles de profesionales escaneando el idioma en busca de vulnerabilidades, es muy probable que sepamos acerca de una buena proporción de las vulnerabilidades en el idioma. Ese conocimiento es poder.

Un artículo reciente de JavaWorld ofrecía 13 reglas para desarrollar aplicaciones Java seguras. También puede encontrar muchos artículos y documentos técnicos sobre la implementación segura de Java en entornos específicos, como la seguridad en la nube para Java y la seguridad de aplicaciones web para Java. Consideremos un par de formas de reducir las vulnerabilidades que quizás haya pasado por alto.

Pasar a un flujo de trabajo de DevSecOps

Una forma de reducir las vulnerabilidades en el código Java es pasar a un flujo de trabajo DevSecOps. Este tipo de flujo de trabajo hace que la seguridad sea una preocupación primordial en todas las etapas del proceso de desarrollo. Como desarrolladores, a menudo olvidamos que nuestro software es utilizado (y algunas veces adaptado) por todas las partes de la organización para la que trabajamos. No es bueno fortalecer sus aplicaciones web contra intrusiones si su equipo de marketing está decidido a socavar sus esfuerzos. Incluya a todos sus equipos en el proceso de desarrollo y asegúrese de que la seguridad sea una consideración para todos los aspectos del proyecto.

Evaluar la seguridad del flujo de trabajo

También debe analizar detenidamente la seguridad de su propio flujo de trabajo. Sus aplicaciones web pueden ser seguras en sí mismas, pero una de las fuentes de vulnerabilidad de más rápido crecimiento para los desarrolladores es el sistema de desarrollo en sí. Si su sistema de desarrollo es pirateado, se convierte en un portal para inyectar código malicioso en su software. Para evitar esto, asegúrese de utilizar una VPN para cifrar todas sus comunicaciones internas. Además, asegúrese de implementar el almacenamiento de datos cifrados.

Conclusión

Aunque la investigación encuentra que Java es menos seguro que algunos otros lenguajes, los desarrolladores deberían tomar ese hallazgo con una pizca de sal. Los lenguajes más nuevos y menos utilizados pueden parecer más seguros, pero es probable que se deba a que muchas de sus vulnerabilidades aún no se han descubierto o, lo que es peor, se han encontrado pero no se han informado.

Si bien debe conocer los riesgos y tomar todas las precauciones razonables para proteger sus aplicaciones Java, no se preocupe demasiado por las clasificaciones. Como desarrollador de Java, al menos sabe a qué se enfrenta.

Esta historia, "¿Qué tan seguro es Java en comparación con otros lenguajes?" fue publicado originalmente por JavaWorld.