En resumen: Posiblemente
Por un lado, sí, este es un riesgo muy real . Con muchas instalaciones de aplicaciones ordinarias y despliegues de bases de datos, esta vulnerabilidad le permitirá acceder a los datos.
Por otra parte, no, un atacante puede ser bloqueado incluso en esta etapa . Existen varias técnicas para mitigar este riesgo. Por ejemplo:
Privilegio limitado en SO . Los comandos arbitrarios que el atacante está ejecutando en el servidor de aplicaciones deben ejecutarse con las credenciales de un usuario particular; Si la cuenta de usuario se ha configurado de acuerdo con el Principle of Least Privilege , es posible que la cuenta de usuario no tenga la autoridad para ejecutar esas órdenes arbitrarias. Idealmente, la cuenta de usuario tendrá permiso para ejecutar la aplicación, pero no hará nada más.
Nota: SELinux es una técnica poderosa para limitar aún más el acceso a los recursos del sistema operativo.
Acceso limitado a DB . Incluso si un atacante descubre las credenciales de la base de datos, puede que no sean de mucha utilidad. La base de datos puede configurarse de modo que estas credenciales solo sean válidas para esa aplicación; por lo tanto, no pueden utilizarse para conectarse a la base de datos a través de ninguna otra herramienta. O bien, la base de datos puede configurarse de modo que estas credenciales solo sean válidas desde esta dirección de cliente; por lo tanto, todas las conexiones de la base de datos del atacante deben ser canalizadas a través del servidor de la base de datos, en lugar de hacerlo desde el propio sistema del atacante.
No hay credenciales de base de datos almacenadas . Una aplicación puede diseñarse para que el usuario ingrese sus credenciales al iniciar sesión, por ejemplo, y éstas se utilicen para acceder a la base de datos. En esta situación, un atacante en el servidor de aplicaciones no pudo conectarse a la base de datos, sin importar cuánto control de nivel de sistema operativo tengan.
Las credenciales de la base de datos se almacenan en otra parte . Una aplicación puede configurarse de modo que obtenga las credenciales de la base de datos de un servicio separado en tiempo de ejecución; este servicio separado puede no permitir conexiones excepto desde la propia aplicación.
Nota adicional: estas técnicas no son exclusivas, por lo que combinarlas puede ser una forma poderosa de limitar el acceso de un atacante. Sin embargo, cada una de estas técnicas requiere una configuración sofisticada no predeterminada, y es probable que una implementación ingenua se pierda todas y cada una de ellas.