Joven hacker sonriendo

Hackeamos su software

cero falsos positivos

Inteligencia experta + tecnología especializada

Establecer Seguridad en Sentencias Dinámicas

Nuestros ethical hackers explican cómo evitar vulnerabilidades de seguridad mediante la programación segura en COBOL al utilizar sentencias SQL dinámicas. Al utilizar bases de datos es importante definir privilegios estáticos, para evitar que los mismos usuarios puedan escalar privilegios.

Necesidad

Seguridad de las sentencias SQL dinámicas para z/OS y OS/400.

Contexto

A continuación se describe las circunstancias bajo las cuales la siguiente solución tiene sentido:

  1. Se está desarrollando una aplicación en el sistema operativo z/OS o OS/400.

  2. La aplicación hace uso de sentencias dinámicas.

  3. Los privilegios para objetos nuevos deben establecerse según el principio de mínimo privilegio (umask)[1].

  4. Los privilegios para un sujeto no pueden ser aumentados por el mismo sujeto[2].

  5. Los privilegios para objetos con contenido o funcionalidad sensible deben tener acceso restringido[3].

Solución

A continuación podrá encontrar un resumen sobre la seguridad de las aplicaciones en el momento de usar sentencias SQL dinámicas[4]. Por lo tanto, se toma en cuenta los siguientes supuestos:

  • La aplicación no hace llamado a procedimientos almacenados[5] o funciones definidas por el usuario.

  • El usuario final está conectado directamente a la base de datos para ejecutar el programa de procesador de SQL.

  • El procesador de SQL está implementado de forma tal que permite ejecutar sentencias de forma libre sin ningún tipo de control.

Tabla 1. Seguridad de las aplicaciones al usar sentencias SQL dinámicas.
¿El procesador de SQL permite ejecución libre de SQL? ¿El usuario tiene la autorización de DB2 para acceder a los objetos? Opción de enlace DYNAMICRULES Implicación de seguridad Análisis

Run

Dentro del procesador SQL: Acceso a objetos autorizados y ejecución de cualquier sentencia SQL.

Acceso desde fuera del procesador SQL es un agujero de seguridad.

Fuera del procesador SQL: Acceso a objetos autorizados y ejecución de cualquier sentencia SQL.

Bind

Dentro del procesador SQL: Acceso a objetos autorizados para el propietario del enlace y ejecución de cualquier sentencia SQL.

* El acceso desde dentro del procesador SQL es probablemente muy permisivo debido a que el propietario del enlace suele tener todos los accesos inclusivos.

* Acceso desde fuera del procesador SQL es un agujero de seguridad.

Fuera del procesador SQL: Acceso a objetos autorizados y ejecución de cualquier sentencia SQL.

No

Run

No hay acceso desde dentro o fuera del procesador SQL.

Sin sentido

No

Bind

Dentro del procesador SQL: Acceso a objetos autorizados para el propietario del enlace y ejecución de cualquier sentencia SQL.

* El acceso desde dentro del procesador SQL es probablemente muy permisivo debido a que el propietario del enlace suele tener todos los accesos inclusivos.

* Sin acceso desde fuera del procesador SQL.

Fuera del procesador SQL: Sin acceso.

No

Run

Dentro del procesador SQL: Acceso a objetos autorizados y sentencia SQL controlada por el procesador SQL.

Acceso desde fuera del procesador SQL es un agujero de seguridad.

Fuera del procesador SQL: Acceso a objetos autorizados y ejecución de cualquier sentencia SQL.

No

Bind

Dentro del procesador SQL: Acceso a objetos autorizados para el propietario del enlace y sentencia SQL controlada por el procesador SQL.

Acceso desde fuera del procesador SQL es un agujero de seguridad.

Fuera del procesador SQL: Acceso a objetos autorizados y ejecución de cualquier sentencia SQL.

No

No

Run

No hay acceso desde dentro o fuera del procesador SQL.

Sin sentido.

No

No

Bind

Dentro del procesador SQL: Acceso a objetos autorizados para el propietario del enlace y sentencia SQL controlada por el procesador SQL.

Configuración más segura.

Fuera del procesador SQL: Sin acceso.




Haz un comentario

Estado de los servicios - Términos de Uso