Protejamos la web (hacia adelante)

Hemos llegado a esperar un nivel razonable de privacidad y seguridad cuando usamos servicios en la web y aplicaciones web. Esto se debe a que estos servicios abarcan todos los aspectos de nuestra vida diaria: desde el dinero y las finanzas hasta la forma en que interactuamos con los servicios gubernamentales; desde nuestra educación o la de nuestros hijos hasta la comunicación con amigos y familiares, la atención médica e incluso algo tan sencillo como comprar comida. Hemos visto las graves consecuencias de las fallas de seguridad: desde filtraciones de contraseñas a gran escala hasta la propagación de malware, spyware y ransomware. Durante los últimos años, he dedicado buena parte de mi tiempo al tema de la privacidad de los usuarios. Cuando interactuamos con todos estos servicios, necesitamos saber que se aplican controles adecuados de privacidad y seguridad. En lo más básico, esto significa contar con conexiones cifradas (por ejemplo, mediante HTTPS). También implica proteger debidamente los datos almacenados y usar correctamente los algoritmos de seguridad y criptografía.

En 2014, organicé un taller de la industria para fortalecer internet frente a la amenaza de la vigilancia generalizada, que, entre otras cosas, pidió que se adoptara HTTPS. Hoy, gracias al esfuerzo de empresas, organizaciones y muchas personas, la gran mayoría del uso de la web se realiza mediante HTTPS. Este esfuerzo de la industria reconoce que la seguridad es un requisito previo para la privacidad. Puedes diseñar una aplicación que proteja la privacidad, pero si no se desarrolla ni se implementa en un entorno seguro, y sus canales de comunicación no están protegidos adecuadamente hasta llegar a la interfaz de usuario, queda expuesta a ataques. Los actores maliciosos explotan cada vez más esta superficie de ataque. Basta con observar la reciente oleada de ataques de phishing, malware y ransomware para ver que tenemos un problema.

Más allá del transporte seguro

Ahora que hemos «resuelto» (o estamos en vías de resolver) el problema del transporte seguro, ¿cuáles son las otras áreas de ataque? En el lado del servidor hay vulnerabilidades como log4j, que los actores maliciosos han aprovechado para atacar endpoints de API de Java. También hay vulnerabilidades del lado del cliente (por ejemplo, vulnerabilidades de cross-site scripting) que amenazan las interacciones con los usuarios en las aplicaciones web. Las vulnerabilidades de cross-site scripting aprovechan las interacciones entre el entorno JavaScript y el Modelo de Objetos del Documento (DOM) del navegador web (o de la vista web de una aplicación empaquetada). Este tipo de ataques del lado del cliente puede exponer los datos privados de un usuario a un atacante o, peor aún, permitirle realizar acciones en su nombre. Este patrón es inherente al funcionamiento de la web (y de muchas aplicaciones). Nos guste o no, vivimos en un mundo donde con un solo toque puedes descargar y ejecutar código de cualquier tercero. Incluso si conoces y confías en ese tercero, su código puede contener vulnerabilidades, especialmente cuando se lleva al mundo real y debe ejecutarse junto con código escrito por muchas otras personas. Y en los ataques de phishing, los actores maliciosos pueden quebrantar fácilmente la confianza de los usuarios.

Cadena de suministro de software

La mayoría de los proyectos de software dependen de dependencias. Los administradores de paquetes, como npm, buscan facilitar su gestión. En NPM, el archivo package.json describe tu proyecto e incluye sus dependencias, pero como solo enumera las dependencias directas, no ayuda demasiado a analizar toda la cadena de suministro de software. Es posible que los desarrolladores no estén acostumbrados a pensar en el desarrollo de software en términos de una cadena de suministro, un concepto que en realidad proviene de la economía. (Y como ya escribí, a algunos desarrolladores puede incomodarles esta terminología). Quizás te preguntes: «¿Ahora todos los desarrolladores de software tienen que convertirse en expertos en seguridad?». La respuesta es sí, más o menos. O, al menos, quienes desarrollan en distintos lenguajes y trabajan en diferentes capas deben conocer los fundamentos de seguridad y empezar a aprender.

Para empezar a pensar en la seguridad de las dependencias de código abierto, un buen recurso para los desarrolladores es la Guía concisa para desarrollar software más seguro de OpenSSF. Esta lista de verificación incluye medidas básicas, como asegurarse de que todos los desarrolladores usen autenticación multifactor al enviar código, y usar herramientas de análisis de vulnerabilidades y monitoreo que sugieren correcciones (como la que ofrece Snyk).

Especificaciones de seguridad avanzadas

Otra frontera en el ámbito de la seguridad de las aplicaciones web es la aparición de API web que habilitan funciones avanzadas con niveles adicionales de seguridad. Por ejemplo, la vulnerabilidad «Spectre» expuso las aplicaciones web que usaban SharedArrayBuffer a ataques a nivel de procesador, capaces de filtrar datos entre contextos que normalmente se considerarían seguros (de distintos orígenes). En respuesta, la comunidad de estándares web desarrolló cross-origin-opener-policy y cross-origin-embedder-policy. Este es un ejemplo de las muchas especificaciones y API nuevas que se han desarrollado en distintos ámbitos para mejorar la seguridad de las API web avanzadas y mitigar este tipo de ataques. Sin embargo, debido a la complejidad inherente del problema y a lo intrincado de algunos de estos enfoques (por ejemplo, la posibilidad de configurar encabezados HTTP en el caso de COOP y COEP), el conocimiento de estas especificaciones por parte de los desarrolladores sigue siendo un problema.

Una cita de un desarrollador incluida en la encuesta MDN Web DNA de 2020 lo resume:

Aunque todavía estoy empezando mi camino en la programación, la seguridad... en internet sigue siendo la principal preocupación. En lo personal, creo que la jerga compleja que se usa para describir cómo funciona la seguridad web en la era moderna hace que aprender e implementar las mejores prácticas de seguridad sea una de las cosas más difíciles para quienes recién empiezan a programar, incluso si optan por soluciones de terceros.

Tenemos que hacer un mejor trabajo para ayudar a los desarrolladores web a implementar las mejores prácticas de seguridad.

Lo que tenemos aquí…

Algo que ha quedado claro al estar con un pie en la comunidad de desarrolladores web y otro en la comunidad de DevSecOps es que necesitamos comunicarnos más. Los desarrolladores web deben empezar a adoptar el mensaje y la mentalidad de la cadena de suministro de software (dependencias) y dar prioridad al análisis de seguridad. La comunidad de desarrolladores que ya presta atención a los problemas de seguridad debe llevar este mensaje a más desarrolladores y tener en cuenta los riesgos de seguridad para los usuarios finales (como los relacionados con la privacidad), que pueden ayudar a explicar por qué el enfoque de DevSecOps es tan importante.

Los desarrolladores web deben involucrarse en la seguridad, no solo como usuarios. Me gustaría ver a más desarrolladores web colaborando con nosotros en OpenSSF. Por ejemplo, en el grupo de trabajo de mejores prácticas de OpenSSF, estamos creando pautas sobre las mejores prácticas de configuración de plataformas de administración de código fuente (p. ej., Github y Gitlab), entre otros temas. Otro ejemplo son las tarjetas de puntuación de OpeSSF, que miden aspectos de seguridad de los repositorios de código abierto. En estas conversaciones ha faltado la voz de la comunidad de desarrolladores web. Y como esa comunidad suele enfocarse más en la privacidad de los usuarios, estos temas han tenido menos protagonismo en el trabajo de OpenSSF del que, a mi parecer, deberían tener. Por eso he trabajado para organizar un taller de la industria que reúna a estas comunidades y ayude a «proteger la web de cara al futuro».

El taller se realizará en Londres los días 7 y 8 de junio. Será un evento abierto de la industria que reunirá algunas de estas voces y, con suerte, impulsará nuevas iniciativas. La convocatoria de propuestas (CfP) para el taller estará abierta hasta el 24 de abril. También podrán asistir los desarrolladores web interesados en la seguridad.