En este artículo vamos a ver otro ejemplo de Inyección SQL. Para ir al primer artículo de esta serie de artículos sobre inyección SQL visita este link: Inyección SQL – Parte I
En una aplicación APEX creamos una página en blanco, luego una región de tipo Informe Clásico y un elemento de tipo texto PX_ENAME
El origen del reporte ingresamos la siguiente consulta SQL:
SELECT * FROM emp WHERE deptno = 10 AND ename LIKE '&PX_ENAME.' (en mi caso es la página 6)
Estamos pasándole en la cláusula del WHERE que muestre los registros que coincidan con el departamento 10 y le pasamos la variable de sustitución de APEX &P6_ENAME. la cual será la entrada que coloque el usuario en el elemento P6_ENAME. Al utilizar el operador LIKE el usuario podría ingresar un % que actuará como un comodín.
Si el usuario no ingresa nada en el elemento y presionamos el botón de ejecutar, no se mostrará nada.
Ahora supongamos que ingresamos el valor KING. Ejecutamos y nos muestra el registro del empleado KING.
Ahora si el usuario ingresa el % y ejecuta, se mostrará todos los registros que sean del departamento 10.
Por ahora el filtro se comporta como nosotros queremos. A pesar de que se está colocando el % que actúa como un comodín, al estar colocando en la cláusula WHERE que el departamento sea igual a 10 estamos limitando a que se muestren solo los empleados de ese departamento.
Ahora si el usuario ingresa esto en el elemento: KING or ‘X’ = ‘X y luego ejecuta el reporte.
Vemos que se muestran todos los registros de la tabla EMP y esto no es la intención de la consulta!
Estamos usando en la consulta SQL del reporte la sintaxis de elementos de APEX en forma incorrecta. Lo que va a hacer APEX, es evaluar y reemplazará todas las variables antes de analizar la consulta SQL por lo tanto, como vimos en la parte 1 de esta serie de entradas, es posible pasar un fragmento de código SQL y hacer que ese fragmento vuelva a escribir la consulta SQL antes de que se analice, cambiándole totalmente la lógica de la consulta, lo que permite que dé a lugar una inyección SQL.
Entonces aquí realizamos la misma solución planteada anteriormente, usamos las variables Bind en vez de la variable de sustitución de APEX.
SELECT * FROM emp WHERE deptno = 10 AND ename LIKE ':P6_ENAME'
Volvemos a ejecutar la página y ahora ya no se muestra ningún registro.
Como la SQL está usando la sintaxis de la variable bind, el intento de cambiar la SQL va a fallar y a menos que exista un empleado que se llame KING or ‘X’ = ‘X …..cosa muy dudosa 🙂 no se van a encontrar datos en la tabla para mostrarse en el reporte. Por lo tanto, la sintaxis de la variable bind se debe utilizar cada vez que una variable deba ser referenciada dentro de cualquier región de SQL o de PL/SQL dentro de APEX, por ejemplo, en la parte de condiciones cuando necesitemos utilizarlas, en los esquemas de autorización, en las acciones dinámicas, o en cualquier otro lugar dentro de APEX cuando estamos usando SQL o PL/SQL con una variable.
Eso sí, hay una excepción a la regla 🙂 esto de usar siempre variables bind; y esto es cuando estamos usando SQL Dinámico en APEX y ese caso lo vamos a ver en el siguiente post. :).
Este ejemplo y muchos otros más ejemplos estan explicados paso a paso en el curso de Seguridad en el siguiente link: Seguridad en Oracle APEX
¡Hasta la próxima!