1

Ataques por Inyección SQL

Proyecto: Ciclo de Vida del Desarrollo Seguro

Gustavo Ladino - 347810
Corporación Universitaria Minuto de Dios
 2

Contenido
1. Introducción ................................................................................................................................ 3
1.1 Propósito ................................................................................................................................... 3
1.2 Personal involucrado ........................................................................................................... 3
1.3 Referencias .......................................................................................................................... 3
1.4 Resumen.................................................................................................................................... 4
2. Descripción General .................................................................................................................... 4
2.1 Perspectiva (enfoque) ............................................................................................................... 4
2.2. Funcionalidad. .......................................................................................................................... 4
2.2.1 Vulnerabilidades................................................................................................................. 4
2.2.1.1 Inyección SQL basada en 1=1 ...................................................................................... 5
2.2.1.2 Inyección SQL basado en “=”....................................................................................... 6
2.2.1.3 Inyección SQL basado en sentencias SQL por lotes .................................................... 7
2.2.1.4 Inyección SQL basado en comentarios de contraseña................................................ 7
2.2.1.5 Inyección basada en excepciones ............................................................................... 7
2.3 Soluciones Propuestas ........................................................................................................ 7
2.3.1 Revisión del código para inyección SQL .......................................................................... 8
2.3.2 Truncamiento cuando se usa QUOTENAME (@variable, ']') ........................................... 9
2.3.3 Ajuste de parámetros con QUOTENAME () y REPLACE () ................................................ 9
3. Referencias ................................................................................................................................ 11
Referencias ........................................................................................................................................ 11
 3

1. Introducción

La inyección SQL es uno de los principales ataques que vulnera la seguridad que ocurre en la capa
de base de datos de una aplicación y amenaza las aplicaciones web. Los hackers utilizan las
inyecciones SQL para obtener acceso a los datos subyacentes y los derechos para recuperar,
eliminar y modificar la información almacenada, la estructura y a los sistemas de administración de
base de datos (DBMS). Un ataque por inyección SQL puede incrustar un código malicioso en una
aplicación mal diseñada y luego pasar a la base de datos back-end. Los datos maliciosos producen
resultados de consulta en la base de datos o acciones que nunca deberían haberse ejecutado. La
inyección SQL se conoce generalmente como una vector de ataque para sitios web, pero puede ser
usado para atacar a cualquier tipo de base de datos SQL. La idea básica es evitar el nivel de servidor
en la aplicación web para obtener acceso al back-end.

1.1 Propósito

Este documento proporciona un entendimiento y comprensión más profunda de los riesgos de

seguridad que amenazan los sitios web. Mejora las prácticas de programación segura para prevenir
problemas de seguridad durante el desarrollo de aplicaciones. Sirve como guía para determinar si
los sitios web han sido correctamente diseñados, desarrollados, y revisados contra todas las
amenazas conocidas. Ayuda a seleccionar las soluciones de seguridad web, y a entender sus
capacidades.

1.2 Personal involucrado

Nombre Gustavo Ladino

Rol Analista, diseñador, programador
Categoría Profesional Informática
Responsabilidad
Información de contacto gladinopinz@uniminuto.edu.co

1.3 Referencias

Título del Documento Referencia

Standard IEEE 830 - 1998 IEEE
 4

1.4 Resumen

En el mundo actual, la inyección SQL es una seria amenaza de seguridad en Internet para las diversas
aplicaciones web dinámicas que residen en Internet. Estas aplicaciones web realizan muchos
procesos vitales en varias empresas basadas en la web. A medida que aumenta el uso de Internet
para diversos servicios en línea, también aumentan las amenazas a la seguridad presentes en la web.
Existe una necesidad universal para todas las aplicaciones web dinámicas y esta necesidad universal
es la necesidad de almacenar, recuperar o manipular información de una base de datos. La mayoría
de los sistemas que administran las bases de datos y sus requisitos, como Oracle Database y SQL
Server, utilizan SQL como su idioma. Sin embargo, el gran uso de las bases de datos basadas en SQL
lo ha convertido en el centro de atención de los piratas informáticos. Aprovechan las aplicaciones
web mal codificadas para atacar las bases de datos. Introducen una consulta SQL aparente, a través
de una entrada de un usuario no autorizado, en la declaración de consulta legítima. En este
documento, intento presentar una revisión exhaustiva de todos los diferentes tipos de ataques de
inyección de SQL presentes, así como la detección de dichos ataques y las medidas preventivas
utilizadas.

2. Descripción General

2.1 Perspectiva (enfoque)

La inyección SQL es un vector de ataque contra apps web, es bien conocido, por esa razón es
recomendable que los administradores de bases de datos y los desarrolladores de aplicaciones
tengan en cuenta buenas prácticas de desarrollo y así evitar las inyecciones de SQL y proteger los
datos.

2.2. Funcionalidad.
2.2.1 Vulnerabilidades
 5

Cuando se usa SQL para mostrar datos en una página web, es muy común que los
usuarios de la web ingresen sus propios valores de búsqueda. Dado que las sentencias
de SQL son solo de texto, es fácil con un pequeño código cambiar dinámicamente las
sentencias de SQL para proporcionar al usuario los datos seleccionados. La inyección
SQL es una técnica en la que los usuarios malintencionados pueden inyectar
comandos SQL en una declaración SQL, a través de la entrada de la página web. Los
comandos SQL inyectados pueden alterar la declaración SQL y comprometer la
seguridad de una aplicación web.

La inyección de SQL generalmente ocurre cuando le pide a un usuario una entrada,

como su nombre de usuario / identificación de usuario, y en lugar de un nombre /
identificación, el usuario le da una declaración SQL que ejecutará sin saberlo en su
base de datos. El código siguiente crea una instrucción SELECT agregando una
variable (txtUserId) a una cadena de selección. La variable se obtiene de la entrada del
usuario (getRequestString):

2.2.1.1 Inyección SQL basada en 1=1

La inyección de SQL basada en 1 = 1 siempre va a ser es verdadera.

Considere que el propósito del código era crear una declaración SQL para seleccionar
un usuario, con un ID de usuario determinado. Si no hay nada que impida que un
usuario ingrese una entrada "incorrecta", el usuario puede ingresar una entrada
"inteligente" como esta:

En el lado del servidor, la consulta se mostrará:

La sentencia SQL es valida y devolvera todas las folas de la tabla “Usuario” ya que la
logica OR 1=1 siempre es verdadera.
 6

2.2.1.2 Inyección SQL basado en “=”

Como en la anterior esta también siempre va a ser verdadera, acá hay un ejemplo:

El resultado será el siguiente código:

SELECT * FROM Users WHERE Name ="Karen" AND Pass ="myPass"

Un hacker obtiene acceso a los nombres de usuario y contraseñas en una base de

datos solo ingresando “OR” “=” en los cuadros de texto de nombre usuario o
contraseña:

El código en el servidor creara una declaración SQL:

SELECT * FROM Users WHERE Name ="" or ""="" AND Pass ="" or ""=""
 7

2.2.1.3 Inyección SQL basado en sentencias SQL por lotes

La mayoría de las bases de datos admiten sentencias SQL por medio de lotes (método
de procesamiento de consultas en el que las consultas procesan varias filas a la vez),
estos lotes van separados por punto y coma. Cada columna dentro de un lote se
almacena como un vector en un área de memoria independiente, por lo que el
procesamiento del modo por lotes se basa en vectores.

SELECT * FROM Users; DROP TABLE Suppliers

La sentencia SQL valida seria:

SELECT * FROM Users WHERE UserId = 105; DROP TABLE Suppliers;

2.2.1.4 Inyección SQL basado en comentarios de contraseña

Partiendo del hecho de que se use el siguiente ID y contraseña:

Username: admin
Password: *****

Si se ejecuta la consulta anterior, entonces esta consulta comprobará el nombre de

usuario y no verificará la contraseña como '-' y es utilizado como un comentario en SQL
y el usuario tendrá acceso a la cuenta sin introducir contraseña.

2.2.1.5 Inyección basada en excepciones

El usuario puede ingresar sintaxis SQL como (' ' ',' ” ',' –') en usuario y contraseña, esto
puede resultar en una excepción y si no se maneja correctamente, puede ser vista en
la interfaz de usuario y da una idea de la implementación del código.
por ejemplo, las clases y el nombre de la tabla sobre la base de qué el hacker puede
extraer más información sobre la tabla y nombre de las columnas.

2.3 Soluciones Propuestas

 8

Este documento propone varias soluciones viables a los desarrolladores para prevenir los
ataques de inyección de SQL. Como principal defensa para prevenir ataques de inyección
SQL es el uso de procedimientos almacenados parametrizados. Cuando se usan estos
procedimientos almacenados las consultas a la base de datos se hacen con subrutinas y

parámetros que son definidos por el usuario en lugar de utilizar comandos.

Figura 1. Buenas prácticas de programación. Tomado de:

https://www.owasp.org/images/9/93/Desarrollo_Seguro_Principios_y_Buenas_Pr%C3%A1cti
cas..pdf

2.3.1 Revisión del código para inyección SQL

Hay que revisar el código EXECUTE, EXEC o sp_executesql, Puede usar consultas
similares a las siguientes para ayudarlo a identificar procedimientos que contienen
estas declaraciones Esta consulta verifica 1, 2, 3 o 4 espacios después de las palabras
EXCUTE o EXEC.

SELECT object_Name(id) FROM syscomments

WHERE UPPER(text) LIKE '%EXECUTE (%'
OR UPPER(text) LIKE '%EXECUTE (%'
OR UPPER(text) LIKE '%EXECUTE (%'
OR UPPER(text) LIKE '%EXECUTE (%'
OR UPPER(text) LIKE '%EXEC (%'
OR UPPER(text) LIKE '%EXEC (%'
OR UPPER(text) LIKE '%EXEC (%'
OR UPPER(text) LIKE '%EXEC (%'
 9

OR UPPER(text) LIKE '%SP_EXECUTESQL%';

2.3.2 Truncamiento cuando se usa QUOTENAME (@variable, ']')

El truncamiento puede ocurrir cuando el nombre de un asegurador de SQL Server se

pasa a las declaraciones que usan el formulario QUOTENAME (@variable, ']'). El
siguiente código muestra un ejemplo:

CREATE PROCEDURE sp_MyProc

@schemaname sysname,

@tablename sysname,

AS

-- Declare a variable as sysname. The variable will be 128

characters.

-- But @objectname actually must allow for 2*258+1 characters.

DECLARE @objectname sysname

SET @objectname = QUOTENAME(@schemaname)+'.'+

QUOTENAME(@tablename)

-- Do some operations.

GO

Cuando concatene valores de tipo sysname, debe usar variables temporales lo

suficientemente grandes como para contener el máximo de 128 caracteres por valor.

2.3.3 Ajuste de parámetros con QUOTENAME () y REPLACE ()

En cada procedimiento almacenado, hay que verificar que todas las variables que se
usan en Transact-SQL dinámico se manejen correctamente. Los datos que provienen
de los parámetros de entrada del procedimiento almacenado o que se leen de una tabla
deben incluirse en QUOTENAME () o REPLACE (). Recuerde que el valor de @variable
que se pasa a QUOTENAME () es de sysname y tiene una longitud máxima de 128
caracteres.

-- Before:
 10

SET @temp = N'SELECT * FROM authors WHERE au_lname ='''

+ @au_lname + N'''';

-- After:

SET @temp = N'SELECT * FROM authors WHERE au_lname = '''

+ REPLACE(@au_lname,'''','''''') + N'''';

Figura 2. Diagrama de flujo prevención inyección SQL. Elaboración propia

 11

3. Referencias

Referencias

[1] Hacksplaining, «hacksplaining.com/lessons,» 2019. [En línea]. Available:

https://www.hacksplaining.com/lessons.

[2] OWASP, «Inyeccion SQL,» 04 12 2014. [En línea]. Available:

https://www.owasp.org/index.php/Inyecci%C3%B3n_SQL.

[3] Microsoft, «SQL Injection,» 15 03 2017. [En línea]. Available: https://docs.microsoft.com/en-

us/sql/relational-databases/security/sql-injection?view=sql-server-2017.

[4] W3Schools, «SQL Injection,» 2019. [En línea]. Available:

https://www.w3schools.com/sql/sql_injection.asp.

[5] OWASP, «Testing for SQL Injection (OTG-INPVAL-005),» 26 04 2016. [En línea]. Available:
https://www.owasp.org/index.php/Testing_for_SQL_Injection_%28OTG-INPVAL-
005%29#Alternative_Expression_of_.27or_1_.3D_1.27.

[6] C. R. C. Diaz, «Desarrollo seguro: Principios y buenas practicas,» 1993. [En línea]. Available:
https://www.owasp.org/images/9/93/Desarrollo_Seguro_Principios_y_Buenas_Pr%C3%A1ct
icas..pdf.

[7] M. Martinez, «OWASP.org,» 04 2017. [En línea]. Available:

https://www.owasp.org/images/c/c8/LatamTour2017_MateoMartinez_SQL_Injection_Deep
Dive.pdf.

[8] C. Michael, «Preventing SQL injection attacks: A network admin's perspective,» 12 2009. [En
línea]. Available: https://searchsecurity.techtarget.com/tip/Preventing-SQL-injection-attacks-
A-network-admins-perspective.

[9] OWASP, «Inyeccion SQL,» 04 12 2012. [En línea]. Available:

https://www.owasp.org/index.php/Inyecci%C3%B3n_SQL.

[10 M. M. D. L. QuintanaIllanes, «Revistas Bolivianas,» [En línea]. Available:

] http://www.revistasbolivianas.org.bo/pdf/rits/n8/n8a17.pdf.

[11 OWASP.org, «OWASP Testing Guide 4.0,» 2019. [En línea]. Available:
] https://www.owasp.org/images/1/19/OTGv4.pdf.
12