Reflexiones sobre los problemas de seguridad de Log4j, lo que implican para la comunidad de desarrolladores en general y el efecto específico en los desarrolladores de RAD Studio.
A menos que viva en una isla remota sin conexión a Internet, seguro que ha oído hablar de los problemas de Log4j que afectaron a tantas aplicaciones y servicios de Internet en los últimos 10 días. El descubrimiento coincidente de este error crítico en el contexto de los mensajes de la consola de Minecraft (escribir un mensaje en el cliente del juego de Minecraft podría permitir que alguien ejecute código en un servidor de Minecraft) debido al uso de una biblioteca de registro de Java extremadamente popular llamada Log4j , provocó que cada Empresa de TI y todas las empresas que utilizan aplicaciones de software para comprobar si el problema afectaba al software de la empresa, los servicios alojados, los sitios web internos y cualquier otro escenario de caso de uso.
La lista de aplicaciones de software afectadas (hay una aquí , por ejemplo) es bastante impresionante, porque a pesar de haber perdido parte de la publicidad y el impulso de marketing, Java es y sigue siendo uno de los lenguajes más populares del mundo, y JVM uno de los más populares. entornos populares de ejecución en tiempo de ejecución.
Código nativo de RAD Studio y sin dependencia de Java
Ahora bien, ¿qué significa esto para Embarcadero en general y RAD Studio en particular? Directamente, no mucho. El software construido en Delphi o C++Builder no usa ni depende de ninguna manera de Java (con la excepción de las aplicaciones de Android) y, por lo tanto, no usa Log4j. Más en general, Delphi y C++Builder crean aplicaciones compiladas de forma nativa, que están menos sujetas a problemas del entorno de ejecución (aquí me refiero a entornos de ejecución Java, .NET o JavaScript). Sin embargo, en este caso, el problema no estaba en el entorno de ejecución, sino en una biblioteca popular, y los desarrolladores de RAD Studio usan componentes complementarios y bibliotecas de terceros, como lo hace cualquier otra comunidad de desarrolladores.
Permítanme aclarar una vez más: un servidor web o servicio web construido en Delphi o C++Builder (o C++ en general) no se ve afectado por el problema de Log4j. Lo mismo es cierto, por supuesto, para las aplicaciones web creadas en ASP.NET, Python o PHP. El problema es específico del software escrito en Java, y hay una gran cantidad de software Java, como se vincula anteriormente.
Volviendo a Delphi y C++Builder, tener código compilado ayuda con la seguridad, pero no es suficiente. También es importante elegir solo bibliotecas y componentes en los que pueda confiar plenamente (como mínimo, que requieran que se incluya el código fuente). Además, también es importante que un desarrollador escriba código con un enfoque específico en la seguridad. Como se mencionó la semana pasada, la codificación de copiar y pegar (si bien no es directamente responsable del problema de Log4j) es un estilo de codificación en la otra cara de la escritura de aplicaciones seguras.
Contribuyendo de vuelta al código abierto
También hay otra cuestión clave que los problemas de Log4j hicieron evidente: hay proyectos multimillonarios gestionados por grandes corporaciones que dependen de proyectos de código abierto sin financiación, gestionados por desarrolladores en su tiempo libre (fuera de sus trabajos habituales). La idea de que puede usar el código abierto para ahorrar costos sin devolver tiempo, recursos o dinero a los proyectos que aprovecha se está convirtiendo en un gran problema en la industria.
Esto también se aplica al ecosistema Delphi y C++Builder: Embarcadero ha comenzado a financiar y donar a algunas bibliotecas de código abierto, pero deberíamos hacer más. También alentamos a todas las aplicaciones comerciales que aprovechan significativamente las bibliotecas y herramientas de código abierto de Delphi a contribuir con ellas, ¡incluso a través de evaluaciones de seguridad!
¿Cuántos proyectos de código abierto usas para tus aplicaciones profesionales y cuándo fue la última vez que donaste a alguno de ellos?
La seguridad es multifacética
La seguridad es un continuo que requiere múltiples ángulos y cada uno de los siguientes elementos puede ayudar:
- Aplicaciones compiladas de forma nativa
- Sin dependencia de un entorno de ejecución en tiempo de ejecución
- Uso de bibliotecas y componentes de terceros examinados y confiables
- Comprometerse a contribuir a los proyectos de código abierto que aprovecha
- Enfoque de seguridad al escribir código (sin codificación de copiar y pegar)
- Herramientas para verificar el código fuente de una aplicación
- Almacenamiento seguro del código fuente (para evitar la inyección de código fuente)
- Entorno de construcción seguro (para evitar la inyección de código binario)
- Firma del ejecutable de la aplicación
Si bien no es exhaustiva y tiene un sesgo hacia el código compilado (realmente creemos que es importante), esperamos que esta lista y la reacción general al incidente de Log4j puedan ayudarlo a usted y a su organización a repensar la seguridad y agregar más valor al rol de los desarrolladores: quienes son la piedra angular de cualquier escenario de desarrollo seguro.
Codificación feliz con su RAD Studio sin Log4j