Forma sugerida de citación: Crespo-Martínez (2021). «Análisis de vulnerabilidades con SQLMAP aplicada a entornos APEX 5». Ingenius. N.° 25, (enero-junio). pp. 103-112. doi: https://doi.org/10.17163/ings.n25.2021.10.

1. Introduction

Varios expertos en seguridad de la información coinciden con que los ataques informáticos cada vez son más recurrentes, y usualmente a los sistemas web, alterando o exponiendo la información personal ^[1], en especial a las aplicaciones web ^[2], debido a su complejidad, extensión, alta personalización y usualmente desarrollados por programadores con poca experiencia en seguridad ^[3]. No se puede negar que, en esta sociedad de la información y el conocimiento, las bases de datos contienen la mina de oro, esta se convierte en uno de los elementos estratégicos más importantes de la organización, pues de su análisis e interpretación en el momento oportuno se pueden proyectar estrategias para aventajar oportunidades y prever amenazas según el rol de la organización en la sociedad.

La protección de la información toma sentido cuando aparecen los primeros virus informáticos: alteraban o borraban la información del usuario, muchas veces con fines de demostrar la capacidad destructora y creativa de quien diseñaba el malware para acometerla. El contexto informático era más simple, no existía la intercomunicación entre organizaciones y los sistemas se limitaban a funcionar de manera centralizada ^[4]. Sin embargo, la explosión de oportunidades que se generan por la introducción de Internet hace que los atacantes vean de otra manera a los datos. Dañarlos o eliminarlos ya no tiene sentido, el robo, la copia o el secuestro son aspectos que se convierten en nuevos objetivos. Ojagbule et al. ^[5] mencionan que, hoy en día, existen más de un billón de sitios web, y que muchos de ellos son desarrollados por gestores de contenido como Drupal, Joomla o WordPress, y que, según Mohammadi & Namadchian ^[6], contienen datos importantes.

Según Ojagbule et al. [5] y Kruegel et al. [6], al existir una gran cantidad de sitios, también existe una gran cantidad de bases de datos que están expuestas a vulnerabilidades y riesgos. De esto aparece una técnica conocida como inyección SQL (Structured Query Language Injection Attack por sus siglas en inglés SQLIA), que según Santin, Oliveira y Lago ^[7] citando a ^[8] y ^[9], es una técnica donde un atacante explora vulnerabilidades que permiten alterar los comandos SQL en una aplicación y que es conocida como una de las vulnerabilidades que generan mayor impacto en la organización. Nofal y Amber [9] agregan que esta técnica usualmente no tiene patrones predecibles o específicos, lo que se convierte en un problema importante para investigadores y desarrolladores. Concluye Badaruddin ^[10] que la técnica de inyección SQL es el segundo error más común encontrado en los servidores web en Internet con alrededor del 44,11 %. Con el propósito de descubrir fallas de seguridaden cuanto a vulnerabilidades de inyección SQL, en este trabajo se realiza una evaluación con SQLMAP a una base de datos Oracle que almacena la información del sistema UDA-ERP desarrollado en APEX 5 por la Universidad del Azuay.

Este artículo se divide en las siguientes secciones: i) el estado del arte, donde se establecen algunos conceptos, así como también los trabajos relacionados; ii) la metodología aplicada para la obtención de los resultados, detallando las configuraciones realizadas en el equipo de laboratorio de pruebas; iii) los resultados obtenidos tras la ejecución de la herramienta; iv) la discusión sobre los resultados adquiridos y v) las conclusiones y trabajos futuros.

1.1. La inyección SQL

Según OWASP, la inyección SQL es una de las diez vulnerabilidades más peligrosas y populares que pueden presentarse en entornos web ^[11], los cuales generalmente son difíciles de proteger debido a su alta personalización, complejidad, escala [3], tecnología y desarrollo por programadores con poca experiencia en seguridad [3], ^[12], causando serios daños a los negocios de las víctimas ^[13]. Sumado a esto, Setiawan y Setiyadi ^[14] sostienen que, en un contexto de redes de computadoras, cualquier dato existente en un computador conectado a otro se vuelve inseguro. Los autores Santin, Oliveira y Lago [7] citando a ^[15] mencionan que no existen soluciones que garanticen o solucionen todas las vulnerabilidades, las cuales ocurren a nivel de hardware y software, expresión a la que se suma Setiawan [14]. Agregan que, como muchos elementos no son actualizados constantemente, son más propensos a ataques cibernéticos. Por otro lado, Kals et al. [12] sostienen que son múltiples las vulnerabilidades de seguridad de aplicaciones web, resultado de problemas genéricos de validación de entrada. Además, las vulnerabilidades pueden mantenerse secretas o reportadas por los fabricantes, sea de forma pública o privada ^[16]. De forma básica, un ataque de inyección SQL puede ser representado como se indica en la Figura 1.

Figura 1. Proceso de la inyección SQL 

Otra forma de representar la secuencia de ataques SQL es la que propone AVI Networks ^[17], la cual se presenta en la Figura 2.

Figura 2. Secuencia de ataque SQL Injection [17] 

De acuerdo con Charania y Vyas ^[18], las técnicas de ataque de inyección SQL pueden clasificarse de la siguiente manera:

• i) Tautologías, un tipo de ataque que utiliza consultas condicionales e inserta tokens SQL en ellas, demostrando siempre ser cierto.

  ii) Consultas ilegales o lógicamente incorrectas, donde los atacantes utilizan los mensajes de error de las bases de datos para encontrar vulnerabilidades en las aplicaciones.

  iii) Consultas con UNION, donde los atacantes inyectan consultas infectadas sobre consultas seguras utilizando el operador UNION y, por lo tanto, recuperar información de la base de datos.

  iv) Consultas con respaldo o Piggy-backed: los atacantes adjuntan delimitadores como ";" a la consulta original y las ejecutan simultáneamente, siendo la primera legítima y las demás falsas, pero retornando información valiosa.

  v) Procedimientos almacenados (Stored procedures), un subconjunto de consultas precompiladas, dependiendo de cuales sean existirán diferentes formas de ataque.

  vi) Inyección ciega o Blind Injection, en la que los desarrolladores ocultan mensajes de error que pueden ser útiles para los atacantes para planificar y ejecutar un ataque SQLIA. En esta situación el atacante se encuentra con una página estática, donde realiza preguntas verdaderas y falsas mediante el uso de comandos SQL hasta conseguir el objetivo.

  vii) Ataques temporizados, que permiten al atacante observar el tiempo requerido para ejecutar una consulta. El atacante genera una consulta grande utilizando sentencias if-else y, de esta manera, medir la cantidad de tiempo que tarda la página en cargarse para determinar si la sentencia inyectada es verdadera.

  viii) Codificaciones alternativas, donde codificaciones ASCII y Unicode permiten evadir el filtro que escanea "caracteres especiales" ^[19].

Una evaluación de vulnerabilidades por inyección SQL puede ser realizada con el uso de herramientas tecnológicas para tal propósito. Novaski ^[20] sugiere el uso de herramientas FOSS, de las cuales propone 14 para ser utilizadas: Arachni, Beef, Htcap, IronWASP, Metasploit, Skipfish, SQLMap, Vega, W3af, Wapiti, Wfuzz, XSSer, Xenotix y ZAP. De este trabajo agrega que solo las herramientas IronWASP, Vega, ZAP y SQLMap detectaron la vulnerabilidad de inyección SQL, mientras que la vulnerabilidad XSS reflejada solo fue detectada por las herramientas ZAP y Xenotix. Indica en su trabajo que solo fue posible realizar una prueba de intrusión completa en la vulnerabilidad de inyección SQL, y para realizarla fue necesario aplicar tres herramientas diferentes: i) wapiti-getcookie, para obtener el identificador de sesión; ii) Htcap para obtener puntos de entrada; y SQLMap para detectar y explotar la vulnerabilidad. Entre los trabajos relacionados están los que se encuentran en la Tabla 1.

Este trabajo, a diferencia de los citados, hace énfasis en probar aspectos de seguridad en una aplicación desarrollada en Oracle APEX 5. Está claro que, a pesar del tiempo transcurrido desde la primera vez que apareció el ataque de inyección SQL hace dos décadas ^[21], son numerosas las técnicas de inyección, así como las técnicas de evasión y mitigación. Las tecnologías de información están cada vez más frecuentes en nuestro entorno y han afectado notablemente el estilo de vida, pues cada vez que aumenta el uso y la confiabilidad en las computadoras y los sistemas informáticos, la amenaza a los datos sensibles también aumenta. Las vulnerabilidades de inyección SQL en las aplicaciones web son sorprendentemente vastas y, definitivamente, son una gran amenaza para la seguridad de los datos personales que se almacenan en la web [21].

En la práctica, Cetin et al. ^[22] demuestran que un análisis automatizado de GitHub enseña que el 15,7 % de los 120 412 archivos fuente de Java publicados contienen código vulnerable a los ataques de inyección de identificador de SQL (SQL-IDIA) señalando, además que, tras una revisión manual, comprobaron que 18 939 archivos Java identificados durante el análisis automatizado son vulnerables a este tipo de ataques. Puneet ^[23] clasifica a la inyección SQL en dos tipos: i) la inyección SQL clásica y ii) la inyección SQL avanzada ⁽²⁴⁾, ⁽²⁵⁾, ⁽²⁶⁾.

Tabla 1. Trabajos relacionados con el uso de SQLMap 

1.1.1. Inyección SQL clásica

Las técnicas de inyección básica, sugeridas por [23] se resumen en las siguientes:

a) Piggy Backed Queries

La intención del ataque es primordialmente la denegación de servicio. La base de datos recibe múltiples consultas, en las que, durante la ejecución, la consulta normal funciona como en un caso normal, mientras que la segunda consulta se adhiere a la primera para conseguir el ataque. Un ejemplo de este ataque puede ser el siguiente:

Posterior a la ejecución de la primera consulta, el intérprete detecta el punto y coma “;” y ejecuta la segunda consulta junto con la primera, eliminando todos los datos del cliente “Francisco”. Este tipo de datos maliciosos pueden protegerse determinando en primer lugar la consulta SQL correcta mediante la validación adecuada o utilizando adecuadas técnicas de detección, como es el análisis estático, que no necesita la supervisión del tiempo de ejecución.

b) Stored procedure

La intención de ataque se resume en autenticación de escape y en denegación de servicio. Erradamente, los profesionales de TI piensan que los procedimientos almacenados de SQL son un remedio para la inyección de SQL [17], ya que se los coloca el frente de las bases de datos y las características de seguridad no son directamente aplicables. Los procedimientos almacenados no usan el lenguaje de consulta estructurado estándar, usa sus propios lenguajes de script que no tienen la misma vulnerabilidad que SQL, pero que mantienen otras diversas vulnerabilidades relacionadas con el lenguaje de scripting. Como ejemplo, se puede indicar lo siguiente:

Cualquier usuario malicioso puede ingresar datos maliciosos en los campos del nombre de usuario y password. Un simple comando ingresado podría destruir toda la base de datos o provocar una denegación del servicio. De esta forma, [23] sugiere que no se acopie información crítica en los procedimientos almacenados.

c) Union query

Es un tipo de ataque que utiliza el operador unión (U) mientras inserta la consulta SQL. Las dos consultas SQL, la normal y la nociva, son unidas mediante este operador. El ejemplo muestra cómo se puede proceder, visualizando que la segunda consulta es maliciosa y no se tiene en cuenta el siguiente texto (-), ya que se convierte en comentario para el Analizador de SQL.

1.1.2. d) Codificación alternativa

Con respecto a este tipo de ataque, el atacante cambia el patrón de la inyección SQL para que no sea detectado por las técnicas comunes de detección y prevención. En este método, el atacante utiliza la representación de código hexadecimal, Unicode, octal y ASCII en la instrucción SQL, evitando ser detectados debido al uso de cadenas codificadas.

1.1.3. Inyección SQL avanzada

Las técnicas de inyección SQL avanzada, sugeridas por [23] se resumen en las siguientes:

a) Inyección SQL a ciegas o Deep Blind SQL Injection Attack

Una gran cantidad de aplicaciones web se deshabilitan la visualización de errores mysql u otro SQL. En este ataque, la información se infiere mediante preguntas de verdadero/falso. Si el punto de inyección es absolutamente ciego, entonces la única forma de atacar es mediante el uso del comando WAIT FOR DELAY o BENCHMARK [23].

b) Fast flux SQL Injection Attack

El objetivo del ataque es la extracción de datos o la suplantación de identidad mediante phishing. Un host que realiza phishing puede ser detectado fácilmente mediante el seguimiento de su dirección IP o la identificación de su nombre de dominio. Sin embargo, concordando con [23] y ^[27], los sistemas de protección de muchos hostings web podrían suspender el servicio debido al masivo tráfico que se genera, anulando los propósitos criminales. De esta manera, para evitar este inconveniente, los atacantes aplican la técnica del Fast Flux, que es una técnica DNS para ocultar los sitios de distribución de phishing y malware detrás de una red de cambio constante.

1.1.4. c) Ataques de inyección SQL compuestos

Se trata de una mezcla de dos o más técnicas de ataque, generando un efecto mayor a los indicados con las técnicas anteriormente descritas. Compounded SQL Injection, como es conocido en el mundo oscuro, es derivada de la mezcla del ataque SQL y otros ataques de aplicaciones web, como, por ejemplo, el ataque de inyección SQL + ataques de denegación de servicio distribuidos (DDoS). Sobre la base de lo que expone [23] citando a ^[28], el código para hacer este tipo de ataque sería:

Otra forma de combinar un ataque es el de mezclar una inyección SQL con la autenticación insuficiente. Este ataque es explotable cuando los parámetros de seguridad no han sido inicializados donde la aplicación falla al identificar la ubicación del usuario, el servicio o la aplicación. Esto permite al atacante acceder a información privilegiada sin la verificación de la identidad del usuario. De esta manera, este tipo de ataque es relativamente más sencillo que con cualquier otro tipo de ataque [23], donde el primer paso es ubicar un sitio web que tenga autenticación insuficiente.

2. Materiales y métodos

El propósito del análisis de seguridad fue el de evaluar la seguridad de una aplicación desarrollada en Oracle APEX, plataforma en la que está desarrollado el software UDA ERP de la Universidad del Azuay. Con esta premisa se configuró un laboratorio considerando los materiales y métodos que se exponen a continuación. Para las pruebas se consideró la suite KALI y se utilizó la herramienta SQLMap, herramienta basada en Free and Open Source, desarrollada sobre una licencia GNU GPLv2 por Miroslav Stampar y Bernardo Damele, considerando que, según Charania y Vyas [18], SQLMap soporta, entre otras, la base de datos Oracle, que es la que utiliza el software UDA ERP.

Acota que SQL soporta seis técnicas de inyección: a ciegas basada en booleana (boolean-based blind), a ciegas temporalizado (time-based blind), basada en error (error-based), basada en consultas UNION (UNION query-based), fuera de banda (out-of-band) y consultas apiladas (stack querys). Las técnicas anteriormente mencionadas forman parte de los parámetros de testeo que están incluidas en SQLMap, las cuales se aplican automáticamente. Utilizando BurpSuite, se ajusta la captura de cookies de sesión, aplicando la configuración de un proxy local (127.0.0.1:8080) con el propósito de capturar las peticiones POST, que posteriormente serán utilizadas con SQLMAP. Previo a la ejecución de las pruebas se actualizaron las dependencias y paquetes de la suite. Reconociendo que SQLMap es una herramienta que permite explorar servidores de bases de datos, para su uso es importante apuntar a la dirección URL que contiene un script SQL.

La estructura “sqlmap -u URL –[parámetros]” es la sentencia común, donde el parámetro -dbs permitirá obtener la base de datos. Posterior a la detección de la vulnerabilidad, se debe usar el parámetro -D y el nombre de la base de datos que será analizada. Si el resultado obtenido es efectivo, el parámetro -tables permitirá recuperar todas las tablas de la base de datos especificada. Con el propósito de identificar las vulnerabilidades, se realizaron tres pruebas, en cada una se incrementó el análisis y se variaron aspectos como el nivel de agresividad en las pruebas, el uso de cookies de sesiones establecidas y la evasión a sistemas de identificación como elaborarlo.

La primera prueba consistió en listar las bases de datos; en la segunda, se aumentó el grado de agresividad y cantidad de pruebas para obtener información de las bases de datos; y en el tercer ataque se pretendió usar un agente aleatorio evadiendo los proxys con el único propósito de capturar una cookie de sesión, elemento que es usado como base para las pruebas automatizadas, en las que se simula una sesión válida de un usuario activo.

3. Resultados

3.1. Primera prueba

La evaluación de vulnerabilidades de la base de datos mediante la ejecución del comando root@kali: /sqlmapdev# python3 sqlmap.py -u –dbs, dio como resultado lo expresado en la Tabla 2, considerando que el ataque generó su propia cookie para evaluación: (’USUARIO=ORA_WWV-cUs...UNNyk6flfB’). La prueba inicia a las 13:03:52 del 2020-03-04 y termina a las 13:04:22 /2020-03-04/

Tabla 2. Resultados de la primera prueba 

3.2. Segunda prueba

En la segunda prueba se ejecutó el comando con las opciones: python3 sqlmap-dev/sqlmap.py - u "http://172.16.1.87:8080/ords/f?p=502" –level=5 – risk=3 -dbs -a –tamper=between. La prueba inicia a las 12:30 del 2020-03-05 y culmina a las 15:18 del 2020-03-05. Con los parámetros seleccionados se aumenta la intensidad del ataque, así como el nivel y cantidad de pruebas. Los resultados se expresan en la Tabla 3.

Tabla 3. Resultados de la segunda prueba 

3.3. Tercera prueba

Se captura la cookie ORA_WWV-W7Hhdq_v8DH8Oli 2Fp4IsyM y se procede a utilizarla mientras la aplicación está activa. Se ejecuta el comando python3 sqlmap-dev/sqlmap.py -u "http://172.16.1.87:8080/ords/f?p=502:1:13479648228 07:::::" –tables –cookie=ORA_WWV-W7Hhdq_v8DH 8Oli2Fp4IsyMR –random-agent –ignore-proxy –level 5, incluyendo un agente aleatorio e ignorando los proxys, pues este último se lo utiliza únicamente con el propósito de capturar cookies, así como también aumentando el nivel de análisis al máximo. Se agrega el módulo de identificación de tablas. El análisis inicia el 2020-03-16 a las 12:21:44. La Tabla 4 refleja los resultados obtenidos.

Tabla 4. Resultados de la tercera prueba 

4. Discusión

Los ataques comunes a sistemas de computación se dan por virus, gusanos y adversarios humanos [3]. La detección de un ataque por inyección SQL puede darse cuando se acostumbra a revisar verificaciones de logs, registros de acceso, detecciones de intrusos entre otras [7], [15], a las que se agrega la aplicación del principio de defensa en profundidad aplicando herramientas como IDS o WAFs [3]. Las evaluaciones continuas a las aplicaciones que se desarrollan y sus certificaciones, previo el paso a entornos en producción, se convierten en otra práctica fundamental, aspecto que usualmente se omite en las organizaciones por el intento de publicar lo antes posible.

La inyección SQL no es una técnica que se aplica con el pulsar de un botón. Se requieren conocimientos sobre el lenguaje SQL. Agrega Clarke [8] que el uso de herramientas para realizar este tipo de acometidas es importante, pues permiten automatizar el ataque. La combinación de herramientas permite obtener resultados más precisos. Concordando con Satin et al. [7] y Ojagbule et al. [5], la aplicación de la herramienta SQLMap para el análisis fue seleccionada por la popularidad, la disponibilidad y el acceso a sus diversas distribuciones, comprobando que herramientas basadas en FOSS permiten lograr resultados tan interesantes como el usar herramientas de pago. Se ha evidenciado que en la base de datos de exploits (https://www.exploit-db.com), el último mecanismo para vulnerar un sistema hecho en APEX fue liberado el 16 de abril del 2009.

A diferencia del trabajo realizado por Clarke (2009) en el que se utiliza una aplicación vulnerable a propósito (en inglés damn vulnerableweb site), desarrollada en PHP con motor de datos MySQL cuyo objetivo es proporcionar una plataforma de pruebas a profesionales que requieran probar sus niveles de destrezas y conocimientos. El resultado de la prueba ‘AND boolean-based blind – WHERE or HAVING clause’ se puede ejemplificar en una página estática, excepto con una pequeña parte donde refleja el valor del parámetro probado (el mismo donde el SQLMap realiza la inyección). En caso de que dicho contenido "reflexivo" no se detecte y neutralice, existe una posibilidad considerable de que la respuesta aparezca como un cambio debido a las cargas útiles de inyección SQL utilizadas (por ejemplo, AND 2 > 3). Por lo tanto, surge el riesgo de detección de falsos positivos (o falsos negativos en algunos casos).

La herramienta, en la primera ejecución, culmina con el argumento de que todos los parámetros evaluados no parecen inyectables, sugiere aumentar el nivel y el riesgo si se desea realizar más pruebas. En sospecha de algún tipo de mecanismo de protección involucrado (ej. WAF), se podría usar la opción ’–tamper’ (e.g. ’–tamper=space2comment’) y/o cambiarlo por ’–random-agent’. El ajuste en la prueba 3 con la configuración del parámetro NIVEL=5 fue necesario para que SQLMap realice la prueba de vulnerabilidad de cookies. La detección y prevención, según [21] se convierte en una tarea difícil si no se comprende adecuadamente el concepto de este tipo de ataques. Realizar evaluaciones binarias, tal como lo proponen ^[29] podría considerarse como una alternativa de mitigación, ya que se trata de un método extremadamente automatizado que detecta y bloquea ataques de inyección SQL en aplicaciones web. Frente a ataques de inyección SQL a ciegas, la técnica más popular es AMNESIA (de las siglas en inglés Analysis and Monitoring for Neutralizing SQLinjection Attacks) ^[30], que es una herramienta aplicable únicamente para proteger las aplicaciones basadas en JAVA y que utilizan monitoreo en tiempo de ejecución [21].

Esta herramienta utiliza algoritmos de aprendizaje de máquina para proveer mecanismos de prevención y detección de amenazas Blind SQL Injection. Otro mecanismo de prevención es el algoritmo de identificación de patrones, propuesto por Aho-Corasick ^[31], algoritmo que tiene dos fases: i) una fase estática y; ii) una fase dinámica. En la fase estática, según ^[32], las consultas SQL generadas por el usuario son comparados con una lista de patrones que contienen una muestra de los patrones de ataque más conocidos. Si la sentencia SQL concuerda exactamente con uno de los patrones dados en la lista de patrones estáticos, significa que se está intentando un ataque SQL. Otra alternativa que propone [31] citando a ^[33] es la SQLRand, donde la idea básica es generar sentencias SQL con el uso de comandos aleatorios en el que la plantilla de consulta dentro de la aplicación pueda ser aleatorizada. En esta forma, los comandos SQL que son inyectados por usuarios maliciosos no son codificados, por cuanto el proxy no reconoce los comandos inyectados haciendo que el ataque no se lleve a cabo. Adicionalmente, [31] mencionando a ^[34], indica que existe un método adicional conocido como el Método de consulta por Token (Query Tokenization Method), en el que se genera un token de la consulta original y de la consulta con inyección. Luego, los tokens resultantes de este proceso se almacenan en un arreglo.

La longitud de arreglos obtenidos de la consulta original y de la consulta con inyección son comparadas, si existe una coincidencia entonces no existe un intento de inyección SQL, caso contrario, se trata de un ataque. A la lista de opciones de mitigación se suma la propuesta de ^[35] que consiste en un enfoque de validación de árbol gramatical, representado en una sentencia. Analizar gramaticalmente una sentencia requiere del conocimiento de la gramática del lenguaje en el que está escrita la sentencia. De tal manera que, cuando el atacante inyecte una consulta SQL maliciosa, entonces el árbol gramatical de la consulta original y la consulta con inyección no coinciden. En esta técnica, la sentencia en particular y la sentencia original son comparadas en tiempo de ejecución. No está demás indicar que la codificación segura es crucial para el diseño de software y sistemas computacionales, aspecto que es omitido por los desarrolladores [12] debido en gran parte al desconocimiento de estándares de codificación segura, negligencia y pérdida de desempeño, a las que se suman las situaciones de usabilidad ^[36].

5. Conclusiones

Una de las características más notables de Oracle APEX es la de crear sesiones con cookies y enlaces URL al software con datos aleatorios. Las pruebas realizadas con la ejecución de las diferentes opciones de los comandos indicadas en esta técnica no permitieron acometer el software con la técnica de inyección SQL a una solución desarrollada en esta plataforma. Si bien una cookie puede ser capturada con Burp Suite, descifrar la misma toma un tiempo considerable. Sin embargo, en ese lapso, Oracle APEX dinámicamente ya generó una nueva cookie haciendo que el ataque por esta técnica sea básicamente imposible. La contribución de este artículo ha sido el de evaluar diferentes técnicas de inyección SQL para enfatizar sobrescritura de código seguro, optimizar las etiquetas por omisión que se generan y así mejorar el nivel de seguridad de una aplicación desarrollada en Oracle APEX, sin olvidar que las pruebas han sido desarrolladas en un lapso temporal, sin eximir vulnerabilidades latentes que puedan presentarse en el día 0.