Feliz cumpleaños inyección SQL, el error que no se puede eliminar

Una versión de este artículo apareció originalmente en Help Net Security. Ha sido actualizado y distribuido aquí.

‍

Si trabajas en un puesto de ciberseguridad práctico, uno que requiera cierta familiaridad con el código, es muy probable que hayas tenido que pensar en la inyección SQL... una y otra vez. Es una vulnerabilidad común que, a pesar de conocerse su remedio bastante sencillo a las pocas semanas de su primer descubrimiento, sigue plagando nuestro software y ofreciendo una pequeña ventana de oportunidad a posibles atacantes si no se detecta antes de la implementación.

El 13 de diciembre de 2020 se cumplieron 22 años de la inyección SQL y, aunque esta vulnerabilidad ya tiene edad suficiente para beber, dejamos que nos supere en lugar de eliminarla de una vez por todas. En agosto de este año, Freepik Company reveló que había sido víctima de un error de inyección SQL que comprometió las cuentas de 8,3 millones de usuarios. Aunque muchos de ellos utilizaban inicios de sesión de terceros (por ejemplo, Google, Facebook), a unos pocos millones se les expusieron contraseñas sin cifrar junto con su nombre de usuario. Lamentablemente para ellos y para muchos otros, las consecuencias de estos incidentes son un gran dolor de cabeza, y recuperar la confianza de la base de usuarios es un proceso a largo plazo.

Mientras "celebramos" este hito con lo que se considera un problema heredado, analicémoslo por un momento. ¿Por qué sigue apareciendo, por qué sigue siendo tan peligrosa que no ha salido del primer puesto de la lista OWASP Top 10 durante años y por qué su solución, relativamente sencilla, no llega a formar parte de los estándares generales de referencia para el desarrollo de software?

¿Por qué sigue siendo relevante la inyección SQL en 2021?

Un vistazo rápido a una brecha reciente de alto perfil, el devastador ciberataque a FireEye, revela un nivel asombroso de sofisticación: fue un ataque altamente coordinado, perpetrado por un Estado-nación, que utilizó una amplia gama de técnicas avanzadas que parecían estar personalizadas para el robo a FireEye. En un comunicado, el CEO de FireEye, Kevin Mandia, dijo:

“Los atacantes adaptaron sus capacidades de clase mundial específicamente para apuntar y atacar a FireEye. Están altamente capacitados en seguridad operativa y ejecutaron el ataque con disciplina y enfoque... utilizaron una combinación novedosa de técnicas que ni nosotros ni nuestros socios habíamos visto en el pasado.”

Es una pesadilla para cualquier CISO, y si algo así puede sucederle a FireEye, pone en perspectiva lo vulnerables que son realmente muchas empresas.

… excepto que son noticias aún peores para la organización promedio. FireEye es una de las empresas de ciberseguridad más reconocidas del mundo, y el ataque exitoso contra ellos requirió que delincuentes de nivel maestro utilizaran todo lo que tenían en una ejecución coordinada a gran escala. Para muchas empresas, una brecha de datos lucrativa podría ser posible explotando un simple error, bastante rápido y sin necesidad de ningún genio. Y la inyección SQL es un ejemplo común de esto último, que sigue siendo aprovechado por aficionados que buscan ganar dinero rápido en la Dark Web.

En mayo de 2020, un hombre fue acusado de tráfico de tarjetas de crédito y delitos de piratería informática, cuando se le encontró con medios digitales que almacenaban cientos de miles de números de tarjetas de crédito activos. Los obtuvo todos utilizando técnicas de inyección SQL, en una operación que comprometió a muchas empresas y a millones de sus clientes.

Como industria, estamos mejorando todo el tiempo, pero la inyección SQL sigue siendo una amenaza importante y afecta a mucho más que a sistemas heredados o sin parches.

Por qué los desarrolladores la mantienen viva (y por qué no es su culpa)

Seguimos diciendo que la inyección SQL es fácil de solucionar y que el código debería escribirse de manera que no la introduzca en absoluto. Como la mayoría de las cosas, solo es fácil cuando te han enseñado a hacerlo bien.

Aquí es donde el proceso de desarrollo de software empieza a fallar. Los desarrolladores cometen los mismos errores, lo que lleva a que vulnerabilidades recurrentes como la inyección SQL se infiltren en el código. Sin embargo, esto no debería ser una sorpresa. La mayoría de los ingenieros terminan su carrera sin haber aprendido mucho sobre codificación segura, si es que aprendieron algo. La mayor parte de la formación en el trabajo es inadecuada, especialmente en un entorno donde la seguridad no se considera una prioridad empresarial en su función.

No les estamos dando a los desarrolladores una razón para preocuparse por la seguridad, ni una plataforma sólida para empezar a ser más conscientes de ella. Los patrones de codificación deficientes mantienen vivos errores como la inyección SQL, y debemos poner más énfasis en la concienciación sobre seguridad de los desarrolladores, además de darles tiempo para escribir código seguro y de mayor calidad. Los patrones de codificación segura pueden tardar más en escribirse, pero el tiempo invertido allí crea eficiencias que son invaluables más adelante en el proceso.

¿Habrá algún día un funeral para la inyección SQL?

La metáfora del funeral es un poco morbosa, pero, en realidad, nuestros datos confidenciales estarían más seguros si la inyección SQL fuera enterrada para siempre. Sin embargo, estoy muy seguro de que celebraremos algunos cumpleaños más antes de que eso suceda, porque la cultura en torno a la seguridad preventiva y el énfasis en la codificación segura simplemente no ha evolucionado lo suficiente como para empezar a cerrar el ataúd.

Lenguajes más nuevos y con mayor seguridad, como Rust, están ayudando a erradicar algunos de los errores con los que hemos lidiado durante mucho tiempo mediante el uso de funciones más seguras, pero existe una enorme cantidad de software heredado, sistemas antiguos y bibliotecas que seguirán en uso y potencialmente vulnerables.

La responsabilidad compartida de la seguridad en el proceso de desarrollo (hola, DevSecOps) será crucial si queremos acabar definitivamente con las vulnerabilidades "fáciles". Se debe involucrar a los desarrolladores desde el principio y apoyarlos para que asuman su parte de responsabilidad en la creación de código más seguro y de mayor calidad.

¿Cómo deberían los desarrolladores abordar la corrección de un error de inyección SQL en su código?

Hemos preparado una guía completa para los desarrolladores que deseen aprender a identificar y corregir la inyección SQL. Con un desafío gamificado en el lenguaje de programación que elijan (¡incluso COBOL!), esta guía ofrece una base de aprendizaje excelente que ayudará a todo desarrollador a crear código más seguro y de mayor calidad.