Una versión de este artículo apareció originalmente en Ayuda a la Seguridad en la Red. Se ha actualizado y sindicado aquí.

‍

Si tienes un papel práctico en la ciberseguridad -uno que requiere cierta familiaridad con el código- es muy probable que hayas tenido que pensar en la inyección SQL... una y otra vez. Se trata de una vulnerabilidad común que, a pesar de conocer su sencillo remedio a las pocas semanas de su primer descubrimiento, sigue plagando nuestro software y proporcionando una pequeña ventana de oportunidad a los posibles atacantes si no se detecta antes de su despliegue.

El 13 de diciembre de 2020 marcó el 22º cumpleaños de la inyección SQL, y a pesar de que esta vulnerabilidad es lo suficientemente vieja como para beber, estamos dejando que se apodere de nosotros en lugar de aplastarla para siempre. En agosto de este año, la empresa Freepik reveló que había sido víctima de un error de inyección SQL que comprometió las cuentas de 8,3 millones de usuarios. Mientras que un número de ellos utilizó inicios de sesión de terceros (por ejemplo, Google, Facebook), unos pocos millones tenían contraseñas sin cifrar expuestas 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 reconstruir la confianza con la base de usuarios es un proceso a largo plazo.

Mientras "celebramos" este hito con lo que se considera un problema heredado, vamos a diseccionarlo por un momento. ¿Por qué sigue apareciendo, por qué sigue siendo tan peligroso que no se ha movido del primer puesto en el Top 10 de OWASP durante años, y por qué su solución relativamente sencilla no entra en los estándares generales de referencia para el desarrollo de software?

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

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

"Los atacantes adaptaron sus capacidades de clase mundial específicamente para atacar a FireEye. Están altamente entrenados en seguridad operativa y ejecutados con disciplina y enfoque... utilizaron una combinación novedosa de técnicas no presenciadas por nosotros o nuestros socios en el pasado.”

Es el combustible de una pesadilla para cualquier CISO, y si algo como esto puede sucederle a FireEye, entonces pone en perspectiva cuán vulnerables son realmente muchas empresas.

... excepto que es una noticia aún peor para la organización promedio. FireEye es una de las compañías de ciberseguridad más reconocidas del mundo, y el ataque exitoso contra ellos requirió de ladrones con nivel de mente maestra que lanzaron todo lo que tenían en una ejecución coordinada y a gran escala. Para muchas empresas, una lucrativa violación de datos podría ser posible explotando un simple fallo, de forma bastante rápida, sin necesidad de ninguna mente maestra. Y la inyección SQL es un ejemplo común de esto último, que sigue siendo aprovechado por los script kiddies 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 encontraron soportes digitales que almacenaban cientos de miles de números de tarjetas de crédito activas. Los cosechó 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 significativa y afecta mucho más que los sistemas heredados o sin parches.

Por qué los desarrolladores lo mantienen vivo (y por qué no es culpa suya)

Seguimos diciendo que la inyección SQL es sencilla de arreglar, y que el código debería estar escrito de forma que no la introduzca en absoluto. Como la mayoría de las cosas, sólo es fácil cuando te han enseñado a hacerlo bien.

Aquí es donde la rueda empieza a tambalearse en el proceso de desarrollo de software. Los desarrolladores cometen los mismos errores, lo que lleva a que vulnerabilidades recurrentes como la inyección SQL se infiltren en el código base. 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 han aprendido algo. La mayor parte de la formación en el puesto de trabajo es inadecuada, especialmente en un entorno en el que la seguridad no se considera una prioridad empresarial en su función.

No 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 la seguridad. Los patrones de codificación deficientes mantienen vivos errores como la inyección de SQL, y tenemos que hacer más hincapié en la concienciación de los desarrolladores en materia de seguridad, así como darles el tiempo necesario para que escriban un código de calidad y más seguro. Los patrones de codificación seguros pueden llevar más tiempo para escribir, pero el tiempo invertido crea eficiencias que son inestimables más adelante en el proceso.

¿Habrá alguna vez un funeral por inyección SQL?

Una metáfora funeraria es un poco mórbida, pero realmente, nuestros datos sensibles estarían más seguros si la inyección SQL fuera puesta a descansar para siempre. Sin embargo, estoy seguro de que celebraremos unos cuantos cumpleaños más antes de llegar a eso, 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 clavar el ataúd.

Los lenguajes más nuevos y robustos en cuanto a seguridad, como Rust, están ayudando a erradicar algunos de los errores con los que hemos lidiado durante mucho tiempo al utilizar funciones más seguras, pero hay 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 que los exploits "fáciles" se cierren definitivamente. Los desarrolladores deben participar en el proceso desde el principio y recibir apoyo para asumir la responsabilidad de su parte en la creación de un código más seguro y mejor.

¿Cómo deben abordar los desarrolladores la corrección de un fallo de inyección SQL en su código?

Hemos elaborado una guía completa para los desarrolladores que quieran aprender a identificar y corregir la inyección SQL. Completada con un desafío gamificado en el lenguaje de programación de su elección (¡incluso COBOL!), proporciona un gran aprendizaje básico que ayudará a todos los desarrolladores a crear un código más seguro y de mayor calidad.