1

Universidad Mariano Gálvez de Guatemala

Facultad de Ingeniería en Sistemas De Información
Maestría en Seguridad Informática
Principios de Seguridad Informática
Ing. José Luis Chávez Cortéz

Tarea
Caso de Estudio 5 – Ataques de Inyección SQL

Kevyn Fernando Villanueva Diagut 1793-19-3379

Ada Bani Castañeda González 1793-16-6862
Martin Manuel Pérez López 1793-18-2388
Alfonso Bernabé Sánchez López 1793-18-5299

Plan Sábado Sección “A”

22 de febrero 2024
2

Contenido

Introducción............................................................................................................ 4 1

Ejercicio 01..................................................................................................... 6 1.1 Nivel:

low ........................................................................................................ 6
 1.2 Descripción ..................................................................................................... 6 1.3

Evidencia de lo realizado ................................................................................ 6 1.4

Explicación del resultado obtenido.................................................................. 6

2 Ejercicio 02..................................................................................................... 8 2.1

Nivel: low ........................................................................................................ 8

2.2 Descripción ..................................................................................................... 8 2.3

Evidencia de lo realizado ................................................................................ 8 2.4

Explicación del resultado obtenido.................................................................. 8

3 Ejercicio 03................................................................................................... 10 3.1

Nivel: low .......................................................................................................10

3.2 Descripción ....................................................................................................10 3.3

Evidencia de lo realizado ...............................................................................10 3.4

Explicación del resultado obtenido.................................................................10 3.5

Descripción ....................................................................................................12 3.6

Evidencia de lo realizado ...............................................................................12 3.7

Explicación del resultado obtenido.................................................................12 3.8

Descripción ....................................................................................................14 3.9

Evidencia de lo realizado ...............................................................................14

3.10 Explicación del resultado obtenido.................................................................14

3.11 Descripción ....................................................................................................17

3.12 Evidencia de lo realizado ...............................................................................17

3.13 Explicación del resultado obtenido.................................................................17

 3.14 Descripción ....................................................................................................19

3.15 Evidencia de lo realizado ...............................................................................20

3.16 Explicación del resultado obtenido.................................................................20

4 Ejercicio 04................................................................................................... 22 4.1

Nivel: medium ................................................................................................22

4.2 Descripción ....................................................................................................22 4.3

Evidencia de lo realizado ...............................................................................23 4.4

Explicación del resultado obtenido.................................................................23 4.5

Nivel: medium ................................................................................................26 4.6

Descripción ....................................................................................................26 4.7

Evidencia de lo realizado ...............................................................................26 4.8

Explicación del resultado obtenido.................................................................26

Conclusiones........................................................................................................ 29

Recomendaciones................................................................................................ 32

Introducción

La seguridad en aplicaciones web es un aspecto crítico en el desarrollo de software

contemporáneo. En este contexto, la Práctica de SQL Injection en Damn Vulnerable Web App

(DVWA) emerge como una experiencia educativa esencial para comprender las

vulnerabilidades y riesgos asociados con la manipulación indebida de consultas SQL en

entornos web.

El propósito fundamental de esta práctica es proporcionar a los maestrandos una

comprensión profunda de la inyección SQL, una de las vulnerabilidades más comunes y

peligrosas en aplicaciones web. Este documento tiene como objetivo guiar a través de los

diferentes niveles de seguridad en DVWA, desde una introducción a los conceptos básicos

hasta técnicas más avanzadas de explotación de vulnerabilidades.

A lo largo del contenido, se abordarán diversas áreas de seguridad en DVWA,

proporcionando una experiencia de aprendizaje secuencial y progresiva.

Cada sección de la práctica se enfocará en aspectos específicos de la inyección SQL,

tales como evadir la autenticación, obtener información privilegiada sobre la base de datos y

exponer contraseñas de usuarios. Cada ejercicio se explicará en detalle, desglosando las

consultas inyectadas y analizando los resultados obtenidos.

El objetivo final de esta práctica va más allá de la mera identificación y explotación de

vulnerabilidades; busca concientizar sobre la importancia de integrar medidas de seguridad

efectivas en el desarrollo de aplicaciones web. Se enfatizará la necesidad de utilizar prácticas

seguras, tales como consultas preparadas, validación de entradas de usuario y la restricción de

privilegios en las cuentas de bases de datos.

En resumen, la Práctica de SQL Injection en DVWA se presenta como una oportunidad

integral para explorar y comprender la inyección SQL, fortaleciendo las habilidades en

seguridad informática y fomentando la adopción de mejores prácticas para garantizar

aplicaciones web más seguras y resilientes.

1 Ejercicio 01

1.1 Nivel: low

1.2 Descripción
 En este punto empezaremos a mostrar datos, para ello estableceremos un escenario

siempre cierto (always true) de manera que mostremos todos los resultados, tanto los falsos

como los ciertos. Introducimos la consulta: sql' or '0'='0

1.3 Evidencia de lo realizado

SELECT first_name, last_name FROM users WHERE user_id = 'Sql' or '0'='0'

1.4 Explicación del resultado obtenido

Vamos a analizar el parámetro que hemos introducido en este ejercicio:

Parámetro introducido: “sql' or '0'='0”.

Este parámetro es un ejemplo clásico de una inyección SQL que busca siempre evaluar

como verdadero el resultado esperado. A continuación, se desglosará la consulta y se

proporcionará una explicación del resultado obtenido:

"sql'": Esto es parte de la consulta original y generalmente se espera que termine con

una comilla simple ('), por lo que estamos cerrando la cadena SQL original.

"or": En SQL, la cláusula "OR" actúa como un operador lógico que devuelve verdadero

si al menos una de las condiciones es verdadera.

 "'0'='0": Esta es la nueva condición que se ha introducido. Estamos comparando una

cadena ('0') con otra cadena ('0'). Dado que ambas cadenas son iguales, la condición siempre

será verdadera, independientemente de los datos reales en la base de datos.

Como resultado, la consulta se comportará como si la autenticación fuera exitosa, y la

aplicación web mostrará todos los resultados disponibles, tanto los falsos como los

verdaderos.

A continuación, mostramos la ejecución de la consulta:

2 Ejercicio 02

2.1 Nivel: low

2.2 Descripción

Mostrar la versión de la Base de Datos. Sql' or '0'=0 UNION SELECT NULL,

version()#

2.3 Evidencia de lo realizado

SELECT first_name,last_name FROM users WHERE user_id=' sql' or '0'=0 UNION

SELECT NULL, version()#'

2.4 Explicación del resultado obtenido

Vamos a analizar el parámetro que hemos introducido en este ejercicio:

Parámetro introducido: "Sql' or '0'=0 UNION SELECT NULL, version()#"

Este parámetro es un ejemplo de una inyección SQL que busca mostrar la versión de la

base de datos. A continuación, se detallará la consulta y se proporcionará una explicación del

resultado obtenido:

- "Sql' or '0'=0": Esto es similar a la consulta del ejercicio #1 y generalmente se espera

que termine con una comilla simple ('), cerrando la cadena SQL original. Además, esperando

que nos devuelva siempre un valor verdadero.

- "UNION SELECT NULL, version()#": Esta es la parte que se utiliza para realizar la

unión con otra consulta. En este caso, se está uniendo con una consulta que selecciona "NULL"

como primer campo y la versión de la base de datos ("version()") como segundo campo.

- "#": El símbolo de almohadilla (#) se utiliza para comentar el resto de la consulta

original y evitar que interfiera con la nueva parte que agregamos.

A continuación, mostramos la ejecución de la consulta:

10

3 Ejercicio 03

3.1 Nivel: low

3.2 Descripción

Ver el usuario que actúa en la base de datos. Sql' or '0'=0 UNION SELECT NULL,

user()#

3.3 Evidencia de lo realizado

SELECT first_name,last_name FROM users WHERE user_id='Sql' or '0'=0 UNION

SELECT NULL, user()#'

 3.4 Explicación del resultado obtenido
Vamos a analizar el parámetro que hemos introducido en este ejercicio:

Parámetro introducido: “Sql' or '0'=0 UNION SELECT NULL, user()#”

Esta consulta es un ejemplo de inyección SQL que busca obtener información sobre el

usuario que está actuando en la base de datos.

11

- "Sql' or '0'=0": Esto es parte de la consulta inicial y generalmente se espera que

termine con una comilla simple ('), y también nos devuelva un resultado verdadero.

- "UNION SELECT NULL, user()#": Esta es la parte que se utiliza para realizar la unión

con otra consulta. En este caso, se está uniendo con una consulta que selecciona "NULL" como

primer campo y el resultado de la función "user()" como segundo campo.

- "#": El símbolo de almohadilla (#) se utiliza para comentar el resto de la consulta

original y evitar que interfiera con la nueva parte que hemos agregado.

En resumen, la consulta original tiene una estructura de unión que combina los

resultados de dos consultas. La primera parte ("Sql' or '0'=0") siempre es verdadera, como en
los ejercicios anteriores, lo que garantiza que se logren evadir las condiciones de autenticación.

La segunda parte ("UNION SELECT NULL, user()#") realiza la unión con una consulta que

selecciona "NULL" como primer campo y el resultado de la función "user()" como segundo

campo. A continuación, mostramos la ejecución de la consulta:

12

3.5 Descripción

Mostrar el nombre de la Base de Datos. Sql' or '0'=0 UNION SELECT NULL,

database()#

3.6 Evidencia de lo realizado

SELECT first_name,last_name FROM users WHERE user_id='Sql' or '0'=0 UNION

SELECT NULL, database()#'

 3.7 Explicación del resultado obtenido
Vamos a analizar el parámetro que hemos introducido en este ejercicio:

Parámetro introducido: “Sql' or '0'=0 UNION SELECT NULL, database()#”

Esta consulta es un ejemplo de inyección SQL que busca obtener información sobre el

nombre de la base de datos.

- "Sql' or '0'=0": Esto es parte de la consulta inicial y generalmente se espera que

termine con una comilla simple ('), y también nos devuelva un resultado verdadero.

13

- "UNION SELECT NULL, database()#": Esta es la parte que se utiliza para realizar la

unión con otra consulta. En este caso, se está uniendo con una consulta que selecciona "NULL"

como primer campo y el resultado de la función "database()" como segundo campo.

- "#": El símbolo de almohadilla (#) se utiliza para comentar el resto de la consulta

original y evitar que interfiera con la nueva parte que hemos agregado.

En resumen, la consulta tiene una estructura de unión que combina los resultados de
dos consultas. La primera parte ("Sql' or '0'=0") siempre es verdadera, como en los ejercicios

anteriores, lo que garantiza que logren evadir las condiciones de autenticación. La segunda

parte ("UNION SELECT NULL, database()#") realiza la unión con una consulta que selecciona

"NULL" como primer campo y el resultado de la función "database()" como segundo campo.

A continuación, mostramos la ejecución de la consulta:

14

3.8 Descripción

Mostrar todas las tablas contenidas en information_schema. sql' and 1=0 UNION

SELECT NULL, table_name from information_schema.tables#

3.9 Evidencia de lo realizado

SELECT first_name,last_name FROM users WHERE user_id='sql' and 1=0 UNION

SELECT NULL, table_name from information_schema.tables#'

 3.10 Explicación del resultado obtenido
Vamos a analizar el parámetro que hemos introducido en este ejercicio:

Parámetro introducido: “sql' and 1=0 UNION SELECT NULL, table_name from

information_schema.tables#”

Esta consulta es un ejemplo de inyección SQL que busca obtener información sobre

todas las tablas contenidas en la base de datos "information_schema".

15

- "sql' and 1=0": Esto es parte de la consulta original y generalmente se espera que

termine con una comilla simple ('), cerrando la cadena SQL original. La condición "1=0" se utiliza

para que la parte original de la consulta nunca sea verdadera, asegurando que no se obtengan

resultados de la consulta original.

- "UNION SELECT NULL, table_name from information_schema.tables#": Esta es la

parte que se utiliza para realizar la unión con otra consulta. En este caso, se está uniendo con

una consulta que selecciona "NULL" como primer campo y el nombre de la tabla ("table_name")

de la base de datos "information_schema.tables" como segundo campo.

- "#": El símbolo de almohadilla (#) se utiliza para comentar el resto de la consulta

original y evitar que interfiera con la nueva parte que hemos agregado.

En resumen, la consulta original tiene una estructura de unión que combina los

resultados de dos consultas. La primera parte ("sql' and 1=0") siempre evalúa como falsa

debido a la condición "1=0", lo que garantiza que se evadan las condiciones de autenticación.

La segunda parte ("UNION SELECT NULL, table_name from information_schema.tables#")

realiza la unión con una consulta que selecciona "NULL" como primer campo y el nombre de la

tabla de "information_schema.tables" como segundo campo.

16

A continuación, mostramos la ejecución de la consulta:

17

3.11 Descripción

En este caso podemos observar campos interesantes almacenados en la base de datos

como:

User_privileges, Session_variables, User_privileges, …

Mostrar los campos de las columnas en information_schema. %' and 1=0 union select

null, table_name from information_schema.tables where table_name like 'user%'# 3.12

Evidencia de lo realizado

SELECT first_name,last_name FROM users WHERE user_id='%' and 1=0 union select
null, table_name from information_schema.tables where table_name like 'user%'#'

3.13 Explicación del resultado obtenido

Vamos a analizar el parámetro que hemos introducido en este ejercicio:

Parámetro introducido: “%' and 1=0 union select null, table_name from

information_schema.tables where table_name like 'user%'#”

18

Esta consulta es un ejemplo de inyección SQL que busca obtener información sobre las

tablas de la base de datos "information_schema" que tienen nombres que contienen la cadena

'user'. Ahora, desglosemos la consulta y proporcionemos una explicación del resultado

obtenido:

- "% and 1=0": Esto es parte de la consulta original y generalmente se espera que

termine con un carácter comodín (%) y una condición que siempre sea falsa ("1=0"). La

condición "1=0" se utiliza para garantizar que la parte original de la consulta nunca sea

verdadera, asegurando que no se obtengan resultados de la consulta original.

 - "UNION SELECT NULL, table_name from information_schema.tables where

table_name like 'user%'#": Esta es la parte que se utiliza para realizar la unión con otra

consulta. En este caso, se está uniendo con una consulta que selecciona "NULL" como primer

campo y el nombre de la tabla ("table_name") de la base de datos "information_schema.tables"

como segundo campo. La condición "where table_name like 'user%'" se utiliza para filtrar las

tablas cuyos nombres contienen la cadena 'user'.

- "#": El símbolo de almohadilla (#) se utiliza para comentar el resto de la consulta

original y evitar que interfiera con la nueva parte que hemos agregado.

En resumen, la consulta original tiene una estructura de unión que combina los

resultados de dos consultas. La primera parte ("% and 1=0") siempre evalúa como falsa debido

a la condición "1=0", lo que garantiza que se puedan evadir las condiciones de autenticación.

La segunda parte ("UNION SELECT NULL, table_name from information_schema.tables

where table_name like 'user%'#") realiza la unión con una consulta que selecciona "NULL"

como primer campo y el nombre de la tabla de "information_schema.tables" como segundo

campo, pero solo para aquellas tablas cuyos nombres contienen 'user'.

19

A continuación, mostramos la ejecución de la consulta:

 3.14 Descripción

Así mostramos todos los campos para cada usuario dentro de la tabla USERS

Mostrar los campos de las columnas.

20

La información que vamos a encontrar son las contraseñas para cada

usuario. Sql' and 1=0 UNION SELECT NULL,

concat(first_name,0x0a,last_name,0x0a,user,0x0a,password) FROM users

# 3.15 Evidencia de lo realizado

 SELECT first_name,last_name FROM users WHERE user_id='Sql' and 1=0 UNION
SELECT NULL, concat(first_name,0x0a,last_name,0x0a,user,0x0a,password) FROM users #'

3.16 Explicación del resultado obtenido

Vamos a analizar el parámetro que hemos introducido en este ejercicio:

Parámetro introducido: “Sql' and 1=0 UNION SELECT NULL,

concat(first_name,0x0a,last_name,0x0a,user,0x0a,password) FROM users #”

Esta consulta es un ejemplo de inyección SQL que busca obtener información sobre los

usuarios, incluyendo sus nombres y contraseñas, de la tabla "users". Ahora, desglosemos la

consulta y proporcionemos una explicación del resultado obtenido:

21

- "Sql' and 1=0": Esto es parte de la consulta original y generalmente se espera que

termine con una comilla simple ('), cerrando la cadena SQL original. La condición "1=0" se utiliza

para que la parte original de la consulta nunca sea verdadera, asegurando que no se obtengan

resultados de la consulta original.

 - "UNION SELECT NULL, concat(first_name,0x0a,last_name,0x0a,user,0x0a,password)

FROM users #": Esta es la parte que se utiliza para realizar la unión con otra consulta. En este

caso, se está uniendo con una consulta que selecciona "NULL" como primer campo y

concatena los campos "first_name", "last_name", "user", y "password" de la tabla "users" como

segundo campo, separados por caracteres de nueva línea ("0x0a").

- "#": El símbolo de almohadilla (#) se utiliza para comentar el resto de la consulta

original y evitar que interfiera con la nueva parte que hemos agregado.

En conclusión, la consulta original tiene una estructura de unión que combina los

resultados de dos consultas. La primera parte ("Sql' and 1=0") siempre evalúa como falsa

debido a la condición "1=0", lo que garantiza que se puedan evadir las condiciones de

autenticación. La segunda parte ("UNION SELECT NULL,

concat(first_name,0x0a,last_name,0x0a,user,0x0a,password) FROM users #") realiza la

unión con una consulta que selecciona "NULL" como primer campo y concatena los campos de

la tabla "users" como segundo campo.

A continuación, mostramos la ejecución de la consulta:

22
 4 Ejercicio 04

4.1 Nivel: medium

4.2 Descripción

Vemos que el parámetro $id se pasa recoge mediante GET y se pasa a la función

mysql_real_escape_string() la cual antepone barras invertidas a los siguientes caracteres: \x00,

\n, \r, \, ', " y \x1a. Probaremos entonces a realizar la misma consulta, pero sin el carácter

especial comilla-simple ‘. 1 or 1=1

23

4.3 Evidencia de lo realizado

4.4 Explicación del resultado obtenido

En el escenario de vulnerabilidad de inyección SQL de nivel medio en DVWA,

observamos que el parámetro id, estaba limitado a un elemento seleccionable, en donde solo

podíamos seleccionar los id de los usuarios existentes. Sin embargo, lo que se hizo fue

inyectar la consulta desde la estructura html de la página, dentro del valor del atributo “value”

del elemento “<option>…</option>” seleccionado por defecto. Podemos ver la parte resaltada

en la figura anterior.

$id se recoge mediante el método POST y luego se pasa a la función

mysqli_real_escape_string(). Esta función tiene la función de agregar barras invertidas a

ciertos caracteres especiales para prevenir inyecciones SQL. Sin embargo, en este caso, se
omite el carácter especial de comilla-simple ('), permitiendo así la explotación de la

vulnerabilidad.

Pasos Realizados:
24

1. Se proporcionó la entrada al parámetro $id a través del método POST,

simulando así un ataque de inyección SQL.

2. A pesar de que la función mysqli_real_escape_string() se utilizó para sanitizar

la entrada, el carácter especial comilla-simple ('), el cual normalmente sería

escapado, fue excluido intencionalmente.

3. La consulta inyectada 1 or 1=1 se ejecutó con éxito, aprovechando la condición

lógica siempre verdadera (1=1).

4. Se observaron los resultados de la consulta, revelando información de todos los

usuarios almacenados en la base de datos.

En resumen, la consulta inyectada 1 or 1=1 ha evadido la autenticación esperada y ha

recuperado información de todos los usuarios en la base de datos, ya que la condición 1=1

siempre es verdadera. La falta de escape para el carácter de comilla-simple permitió que la

inyección SQL tuviera éxito, subrayando la importancia de implementar técnicas de sanitización

adecuadas y de asegurar una capa de seguridad sólida en el manejo de consultas SQL para

prevenir este tipo de ataques.

25

A continuación, mostramos la ejecución de la consulta:

 26

4.5 Nivel: medium

4.6 Descripción

En esta ocasión se hará una prueba de un sistema que hace referencia al nombre de la

tabla en hexadecimal expuesto en un trabajo final de master en la Universidad de Almería

(Waysen Restoin, Javier y Pérez Sánchez, Francisco Javier). Según este trabajo se puede

extraer toda la información de la tabla users haciendo referencia a su nombre en hexadecimal:

0x7573657273.

1 and 1=0 UNION SELECT table_name, column_name from

information_schema.columns where table_name=0x7573657273

4.7 Evidencia de lo realizado

 4.8 Explicación del resultado obtenido
En el escenario de vulnerabilidad de inyección SQL de nivel medio en DVWA,

observamos que el parámetro id, estaba limitado a un elemento seleccionable, en donde solo

podíamos seleccionar los id de los usuarios existentes. Sin embargo, lo que se hizo fue

inyectar la consulta

27

desde la estructura html de la página, dentro del valor del atributo “value” del elemento

“<option>…</option>” seleccionado por defecto. Podemos ver la parte resaltada en la figura

anterior.

En este ejercicio de inyección SQL de nivel medio en DVWA, se exploró una

vulnerabilidad que involucra la manipulación del nombre de la tabla en hexadecimal. La

aplicación, al no validar adecuadamente la entrada del usuario, permite la ejecución de

consultas SQL maliciosas.

Pasos Realizados:

1. Se proporcionó la entrada al parámetro $id a través del método POST, imitando

un ataque de inyección SQL.

 2. La consulta inyectada 1 and 1=0 UNION SELECT table_name, column_name

from information_schema.columns where table_name=0x7573657273 se

diseñó para extraer información de la tabla users en formato hexadecimal

(0x7573657273).

3. La aplicación ejecutó la consulta inyectada con éxito, revelando los nombres de

las columnas de la tabla users en la base de datos.

En conclusión, la consulta inyectada explotó la vulnerabilidad en la aplicación al

referenciar la tabla users en formato hexadecimal. Esto permitió recuperar los nombres de todas

las columnas de la tabla users en la base de datos, revelando información sensible sobre la

estructura de la base de datos. Este hallazgo destaca la importancia de validar y sanitizar

adecuadamente las entradas del usuario para prevenir ataques de inyección SQL y garantizar la

seguridad de la aplicación.

28

A continuación, mostramos la ejecución de la consulta:

29

Conclusiones
 En el transcurso de la práctica de SQL Injection en Damn Vulnerable Web App (DVWA),

se han identificado hallazgos clave que arrojan luz sobre la vulnerabilidad crítica de inyección

SQL y sus implicaciones en la seguridad de las aplicaciones web. Esta evaluación se presenta

de manera objetiva, sin perder de vista el propósito de comprender y abordar las

vulnerabilidades asociadas con este tipo de ataques.

Hallazgos Clave:

Los datos y descubrimientos más destacados revelan la capacidad de evadir la

seguridad y obtener acceso no autorizado a información sensible mediante técnicas de

inyección SQL. Estos hallazgos respaldan de manera concluyente la hipótesis de que la

inyección SQL puede comprometer la integridad y confidencialidad de los datos en aplicaciones

web.

La capa de seguridad en aplicaciones web, particularmente en el manejo de consultas

SQL, juega un papel importante en la mitigación de vulnerabilidades. La falta de validación y

sanitización adecuadas de las entradas del usuario deja a las aplicaciones expuestas a ataques

de inyección SQL. Los resultados de esta práctica subrayan la importancia de implementar

medidas efectivas en esta capa, como consultas preparadas, para prevenir con éxito ataques

de inyección SQL.

30

Relación con Objetivos de la Investigación:

Cada uno de los ejercicios realizados en DVWA estuvo directamente alineado con los

objetivos de la investigación, proporcionando una comprensión detallada de cómo estas

vulnerabilidades pueden ser explotadas y subrayando la necesidad de fortalecer las defensas

contra ataques de inyección SQL.

 Implicaciones:

Las implicaciones de estos hallazgos son significativas para el campo de la seguridad

informática. La capacidad de manipular consultas SQL puede tener consecuencias

perjudiciales, desde el acceso no autorizado hasta la exposición de información confidencial.

La importancia de abordar estas vulnerabilidades radica en la preservación de la integridad y

seguridad de las aplicaciones web, siendo esencial para la protección de datos sensibles.

Limitaciones y Áreas para Futura Investigación:

Es fundamental reconocer las limitaciones de esta práctica, como el entorno controlado

de DVWA. Futuras investigaciones podrían expandir el alcance a entornos del mundo real,

explorar nuevas variantes de inyección SQL y desarrollar estrategias de mitigación más

avanzadas para fortalecer aún más la seguridad en aplicaciones web.

La conclusión reafirma la importancia de abordar activamente las vulnerabilidades de

inyección SQL en el desarrollo de aplicaciones web. La seguridad debe considerarse como una

31

prioridad central para evitar riesgos potenciales y proteger la confianza de los usuarios en

entornos digitales cada vez más interconectados.

En resumen, esta investigación subraya la necesidad crítica de implementar prácticas de

seguridad robustas para prevenir y mitigar ataques de inyección SQL. Al reconocer la magnitud

de las amenazas potenciales, se convierte en un llamado a la acción para que la comunidad de

desarrollo y seguridad informática refuerce sus esfuerzos y adopte enfoques proactivos hacia la

protección de aplicaciones web. La inyección SQL no solo es una vulnerabilidad, sino una

advertencia constante sobre la urgencia de mantener la seguridad digital en un entorno en

constante evolución.

32

Recomendaciones

1. Implementación Rigurosa de Consultas Preparadas:

• Fundamentación: La adopción de consultas preparadas es esencial para prevenir

inyecciones SQL al parametrizar las consultas y evitar la concatenación de datos de

entrada del usuario directamente en las consultas SQL.

• Relación con Hallazgos: Aborda directamente la vulnerabilidad de inyección SQL,

ofreciendo una barrera efectiva contra los ataques.

2. Validación y Sanitización de Entradas de Usuario:

• Fundamentación: La validación rigurosa y la sanitización de las entradas del usuario

reducen el riesgo de inyecciones SQL al garantizar que solo se acepten datos válidos y

seguros.

• Relación con Hallazgos: Contrarresta la manipulación de entradas del usuario,

fortaleciendo la capa de seguridad contra ataques.

3. Auditorías Regulares de Seguridad:

• Fundamentación: Realizar auditorías periódicas permite identificar y abordar

rápidamente nuevas vulnerabilidades o posibles brechas de seguridad.

• Relación con Hallazgos: Contribuye a mantener un entorno seguro y a prevenir futuros

 ataques de inyección SQL.

4. Capacitación Continua del Personal de Desarrollo:

33

• Fundamentación: La formación constante en prácticas seguras de desarrollo sensibiliza

al equipo sobre la importancia de mitigar las vulnerabilidades, como la inyección SQL. •

Relación con Hallazgos: Mejora la cultura de seguridad en el desarrollo de software.

5. Implementación de Cortafuegos de Aplicación Web (WAF):

• Fundamentación: Los WAF pueden detectar y bloquear patrones de inyección SQL,

proporcionando una capa adicional de seguridad.

• Relación con Hallazgos: Refuerza la protección contra ataques de inyección SQL a nivel

de aplicación.

6. Seguimiento Continuo y Evaluación de las Medidas de Seguridad:

• Fundamentación: Establecer métricas y evaluar regularmente la efectividad de las

medidas de seguridad permite ajustar y mejorar las defensas.

• Relación con Hallazgos: Proporciona una forma de medir el éxito y adaptarse a las

amenazas emergentes.

7. Priorización de Correcciones según el Nivel de Riesgo:

• Fundamentación: Enfocarse en corregir las vulnerabilidades de inyección SQL de mayor

riesgo primero garantiza una asignación eficiente de recursos.

 • Relación con Hallazgos: Aborda de manera proactiva las vulnerabilidades más críticas.

8. Documentación Exhaustiva de Buenas Prácticas de Seguridad:

• Fundamentación: Proporcionar orientación clara y documentar las mejores prácticas de

seguridad facilita su adopción y cumplimiento por parte del equipo de desarrollo. • Relación

con Hallazgos: Promueve una cultura de seguridad desde el diseño.

34

9. Consideración de Posibles Obstáculos:

• Fundamentación: Reconocer posibles desafíos, como la resistencia al cambio o la

limitación de recursos, ayuda a anticipar y abordar obstáculos en la implementación de

medidas de seguridad.

• Relación con Hallazgos: Demuestra una comprensión realista de la implementación de

recomendaciones.

10. Involucramiento Activo de las Partes Interesadas:

• Fundamentación: Fomentar la participación y el compromiso de todas las partes

interesadas fortalece la implementación exitosa de medidas de seguridad. •

Relación con Hallazgos: Aborda la necesidad de una cooperación integral para

garantizar la seguridad efectiva en aplicaciones web.