Modernizar el mantenimiento de reglas SAST para detectar vulnerabilidades más rápido

Snyk Code se distingue de la mayoría de las herramientas de análisis estático de código porque genera y mantiene conjuntos de reglas para sus usuarios, lo que les ayuda a combatir amenazas comunes y recién descubiertas. Un artículo reciente de Hub describió una nueva vulnerabilidad de JavaScript llamada contaminación de prototipos, que permite a los atacantes modificar o «contaminar» el prototipo de un objeto de JavaScript y ejecutar diversas acciones maliciosas.

En esta publicación, usaremos el ejemplo de la contaminación de prototipos para explicar cómo las funciones de mantenimiento de reglas de Snyk Code ayudan a desarrolladores y profesionales de seguridad a proteger sus aplicaciones. No analizaremos esta vulnerabilidad en profundidad, pero si quieres aprender más, te recomiendo tomar esta lección de Snyk Learn o leer el artículo de Hub mencionado anteriormente.

El enfoque tradicional para mantener conjuntos de reglas

La calidad de una herramienta de pruebas de seguridad de aplicaciones estáticas (SAST) —y, en términos más generales, de las herramientas de análisis estático de código— depende en gran medida de la calidad de su conjunto de reglas. En pocas palabras, la herramienta transforma el código fuente en una estructura de datos y usa estas reglas para buscar patrones maliciosos. En la mayoría de los escáneres modernos, las reglas se escriben en un estilo poco común llamado programación lógica.

Escribir y mantener conjuntos de reglas no es una tarea sencilla. Requiere conocimientos profundos de programación lógica, así como del lenguaje y las bibliotecas que se analizan. Una vez escritas las reglas, depurarlas plantea otro desafío. Deben probarse con código real antes de usarse en producción, un proceso que puede llevar horas fácilmente. Como resultado, una investigación1 mostró que los desarrolladores rara vez cambian la configuración. Aunque hay algunos casos en los que tienen sentido las reglas personalizadas, en la mayoría de ellos la herramienta simplemente debería funcionar.

Nota: Hay algunos casos muy específicos en los que las reglas personalizadas tienen sentido (si es tu caso, cuéntanos). En la mayoría de los casos, la herramienta debería «simplemente funcionar», ¡sin que el usuario tenga que hacer ajustes!

Snyk Code moderniza el mantenimiento de reglas

Snyk Code adopta un enfoque diferente. Consideramos que el conjunto de reglas forma parte del producto y no les pedimos a nuestros clientes que lo mantengan para poder usar la herramienta. En un sector que considera que las «reglas personalizadas» son una capacidad indispensable de una herramienta SAST, Snyk ofrece a sus usuarios una solución más sencilla. Nuestros expertos en seguridad se encargan de crear y mantener el conjunto de reglas con un motor potente y rápido, usando una gran cantidad de proyectos de código abierto como conjuntos de prueba y entrenamiento. El equipo de Snyk mantiene a personas en el proceso para supervisar continuamente los resultados y controlar su calidad, para que nuestros clientes no tengan que hacerlo.

Uno de los ingenieros de Snyk que trabaja en el mantenimiento de reglas es Alessio Della Libera, investigador de seguridad que se unió a Snyk hace aproximadamente un año. Al preguntarle sobre el enfoque único de Snyk Code, lo describió como «[...] una especie de ciclo. Empezar a cambiar algo y comprobar los cambios con los resultados del conjunto de datos toma unos minutos. Poder iterar tan rápido es muy útil».

Un análisis más profundo

El conjunto de entrenamiento de proyectos de código abierto se supervisa y actualiza continuamente según los resultados de los análisis y los comentarios de los usuarios. Durante esta supervisión, Libera se dio cuenta de que una de nuestras reglas existentes no se comportaba según lo esperado.

Después de modificar la regla y probarla, dos resultados llamaron la atención. El proyecto de código abierto appwrite.io incluía una copia de la biblioteca litespeed.js. Según su sitio web, «Appwrite es una solución autohospedada que ofrece a los desarrolladores un conjunto de API REST fáciles de usar e integrar para gestionar sus necesidades principales de backend». Snyk Code informó el mismo problema tanto en la biblioteca disponible en el marketplace como en el propio proyecto.

En una instancia activa de appwrite.io (por ejemplo, mientras se ejecuta en mywebsite.com), un atacante puede llamar a mywebsite.com/auth/signup?__proto__[polluted]=yes. Con las herramientas para desarrolladores del navegador, puedes revisar el estado de JavaScript y ver que ahora hay un miembro llamado polluted con el valor yes. Al explotar este problema, Libera descubrió que sitios web maliciosos podían aprovechar esta vulnerabilidad para desencadenar un ataque de cross-site scripting (XSS).

Informar a los encargados del mantenimiento

Tras informar a los encargados del mantenimiento del proyecto Appwrite, estos lanzaron rápidamente parches para cubrir el paquete appwrite/server-ce y el paquete litespeed.js. Como la aplicación se usa ampliamente, también se publicó un CVE en la National Vulnerability Database.

Una vez resuelta la vulnerabilidad, los encargados del mantenimiento de Appwrite le ofrecieron a Libera una tarjeta de regalo, que pidió donar en beneficio de la comunidad de código abierto. En general, no podemos más que reconocer la manera en que Appwrite gestionó el problema de seguridad. Al tomarlo en serio y colaborar con la comunidad para resolverlo, ayudaron a mantener la seguridad del código abierto.

Resumen

Al desarrollar y mantener continuamente los conjuntos de reglas que impulsan Snyk Code, Snyk garantiza una mejora constante en la precisión de la cobertura. Nos aseguramos de buscar continuamente nuevos patrones de problemas e implementarlos, mientras mantenemos las reglas existentes. Para nosotros, el conjunto de reglas forma parte del producto y es nuestra responsabilidad crearlo y mantenerlo.

Prueba Snyk Code gratis hoy y descubre cómo nuestra plataforma de seguridad centrada en desarrolladores te ayuda a escribir código de alta calidad con más eficiencia que nunca.

1 Beller, M., Bholanath, R., McIntosh, S., & Zaidman, A. (2016). «Analyzing the state of static analysis: A large-scale evaluation in open source software». 2016 IEEE 23rd International Conference on Software Analysis, Evolution, and Reengineering, SANER 2016, 1, 470–481. https://doi.org/10.1109/SANER.2016.105