Muchos servicios ofrecidos en Internet, como correo electrónico, sftp y juegos en línea, pueden hacer autenticación contra las bases de datos relacionales. El módulo PAM para Postgres es un ejemplo, ya que tenía una vulnerabilidad de inyección de SQL .
Aunque no es común hacer registro en una base de datos, esto puede ser útil en algunas situaciones. El agregador de la base de datos del marco de registro de Java log4j no realizó ninguna entrada de escape en las versiones realmente anteriores de log4j.
Esos dos casos anteriores se detectan con bastante facilidad en una auditoría. El caso más interesante, sin embargo, desde mi punto de vista es el siguiente:
Dada una aplicación para empleados que ha estado en uso durante décadas. Cuando el software se desarrolló hace mucho tiempo, la seguridad no era un problema (por ejemplo, porque los empleados podrían hacer mucho más daño al ingresar números incorrectos o porque se hizo usando permisos ajustados en el nivel de la base de datos).
Sabes esas viejas aplicaciones feas, nadie sabe cómo funcionan y nadie quiere tocarlas. Si se acepta el riesgo de que los empleados hagan cosas malas, esto funciona bien.
Avance rápido: Internet es genial. Los clientes deben ingresar sus datos en una aplicación web ellos mismos. La aplicación de internet está debidamente auditada. Incluso podría usar una base de datos en la sombra.
Pero al final, los datos ingresados por personas que no son de confianza ahora se procesan utilizando la aplicación anterior. Si dichos datos se guardan de nuevo en la base de datos o se utilizan en la consulta, las instrucciones SQL inyectadas se ejecutan con los permisos de la base de datos del empleado. (Lo siento, no hay referencias, pero he visto que es muy frecuente en el mundo real. A veces esto no se descubre hasta que un cliente tiene un nombre que incluye una ').
