YECCIÓN SQL Trabajo final de investigación aplicada ...
76
UNIVERSIDAD DE COSTA RICA SISTEMA DE ESTUDIOS DE POSGRADO EVALUACIÓN DE METODOLOGÍAS DE DEFENSA PARA ATAQUES DE I::\YECCIÓN SQL Trabajo final de investigación aplicada sometido a la consideración de la Comisión del Programa de Estudios de Posgr.$.do en Computación e Informática para optar al grado y título de Maestría Profesional en Computación e Informática ISAÍAS JESÚS CHAVARRÍA MORA Ciu<la<l Universitéufa Rodrigo Facio, Costa Rica 2017
Transcript of YECCIÓN SQL Trabajo final de investigación aplicada ...
UNIVERSIDAD DE COSTA RICA
SISTEMA DE ESTUDIOS DE POSGRADO
EVALUACIÓN DE METODOLOGÍAS DE DEFENSA PARA ATAQUES DE
I::\YECCIÓN SQL
Trabajo final de investigación aplicada sometido a la consideración de la
Comisión del Programa de Estudios de Posgr.$.do en Computación e Informática
para optar al grado y título de Maestría Profesional en Computación e
Informática
ISAÍAS JESÚS CHAVARRÍA MORA
Ciu<la<l Universitéufa Rodrigo Facio, Costa Rica
2017
XX
DEDICATORIA
A mis padres por haberme formado como la persona que soyi los valores y
principios que rigen mi vida desde mi niñez) por haberme enseñado a trabajar
duro y esforzarme por mis metas y objetivos) a salir adelante a pesar de las limi
taciones.
A mi esposa Lizeth Castro Cabezas y mi hija Amy Samantha Chavarría Cas
tro, ustedes son el motor que rige mi vidai mi motivación y la razón por la cual
cada día me despierto queriendo ser una persona mejor y un mejor profesional.
Por ustedes y para ustedes.
11
AGRADECIMIENTOS
A mi Dios por su amor y su bondad para conmigo, por permitirme la vida
para luchar por mis anhelos, por darme la fuerza y las posibilidades para lograr
los, Bendito sea mi Dios.
A mi amada esposa por haberme acompañado los últimos once años de mi
vida, y por continuar a mi la.do el día de hoy. Han sido muchos los sacrificios y el
apoyo recibido de tu parte tienen un valor inconmensurable en mi corazón.
A mi profesora tutora Ga.briela Barrantes Sliesarieva, por su gran apoyo du
rante todo el profeso de la maestría, su conocimiento y enseñanzas fueron de gran
importancia para este proceso, usted realmente hace una diferencia en su trabajo,
muchísimas gracias.
III
"Este trabajo final de investigación aplicada fue aceptado por la. Comisión del Programa. de Estudios de Posgrado en Computación e Informática. de la Universidad de Costa Rica, como requisito parcial para optar al grado y título de Maestría Profesional en Computación e Informática"
Dr. Ricardo Villalón Fonseca
Representante del Decano
Sistema de Estudios de Posgrado
Profesora Guía
/
Dra. Gabriela Marín Ravcntós
Directora
Programa de Posgrado en Computación e Informática
Isa.ías Jesús Chavarría Mora
Sustentante
Ciudad Universitaria Rodrigo Facio, Co::;ta Rica
2017
IV
, Indice
l. INTRODUCCIÓN 1
4
4
4
2.
1.1. Objetivo ..
1.2. Justificación
1.3. Alcances . .
MARCO TEÓRICO
2.1. Técnicas de inyección de código SQL
2.1.1. Tautologías
2.1.2. Unión de Consultas
2.1.3. Combinación de estatutos
- - 1
2.1.4. Sentencias incorrectas lógicamente .
2.1.5. Procedimientos almacenados
2.1.6. Inferencias . , . . .
2.1.7. Codificaciones alternativas
2.2. Defensas evaluadas -
2.2.1. SQLRand
6
6
6
7
7
8
9
10
11
12
12
2.2.2. Detección de inyección SQL basado en árboles de decisión 16
2.3. Herramientas utilizadas . . 19
2.3.1. Comunicación entre máquinas 19
2.3.2. Weka. . . . 20
2.3.3. SQLMap 22
3. METODOLOGÍA 24
3.1. Modelo de Amenaza 24
3.2. Aplicación vulnerable . 25
3.3. Implementación de SQLRand 26
3.3.1. Implementación del modelo en SQLRand 26
3.3.2. Variable de respuesta en SQLRand 29
3.4. Implementación en Árboles de decisión . . 30
3.4.1. Implementación del modelo en Árboles de decisión . 30
V
3.4.2. Variable de respuesta en Árboles de decisión
3.5. Evaluación
3.5.1. Evaluación en SQLrand
3.5.2. Evaluación en detección por árboles de decisión
3.6. Comparación de las metodologías
4. RESULTADOS Y ANÁLISIS
4.1. Resultados en SQLRand
4.2. Resultados en Árboles de decisión
4.2.1. Análisis detallado de atributos .
4.2.2. Atributos numéricos .
4.2.3. Atributos no numéricos .
4.3. Comparación de Resultados
4.3.1. Comparación cuantitativa
4.3.2. Comparación cualitativa
5. TIEMPOS DE RESPUESTA
5.1. Tiempos de respuesta en SQLRand
39
40
41
42
43
43
45
49
49
50
52
52
54
54
55
5.2. Tiempos de respuesta en árboles de decisión 55
6. CONCLUSIONES 57
7. TRABAJO FUTURO 58
8. ANEXOS 59
8.1. Tiempos de proceso para generar entrada del árbol de decisión 59
VI
RESUMEN
Con el crecimiento en la cantidad de aplicaciones web, se a.ument.a también
la vulnerabilidad ante atacantes que desean apoderarse de los datos que son ma
nejados por estas aplicaciones, o incluso causar daños a la infraestructura de la
aplicación. De los ataques <le inyección de código conocidos, la inyección <le SQL
es la más común y la que ha causado más daños en los últimos años. En este
trabajo se presenta una evaluación y comparación entre dos técnicas creadas pa
ra prevenir los ataques de inyección de SQL, SQLRand y Detección basada en
Árboles de Decisión, con el fin de apoyar la toma de decisiones en cuanto a su uso
en aplicaciones web. Como resultados, se muestra el porcentaje de efectividad de
cada metodología en la detección de ataques de inyección SQL, además del análi
sis del costo que representa la implementación y el conocimiento previo requerido.
Palabras clave: Inyección SQL, SQLRand, Detección por Árboles de deci
sión, Evaluación
VII
ABSTRACT
With the increase of web applications usage, the probability of being hacked
has increase as well. Hackers might obtain access to prívate data, and/ or damage
enterprise data and infrastructure. The most common code injection attack is
SQL injection, one that has caused the most damages lately. In this work, we
present an evaluation and comparison between two proposed techniques far SQL
injection prevention: SQLRand and Decision-Tree based detection, with the pur
pose of providing guidance and support for the hardening of web applications.
The results are showed in terms of effectiveness of each technique for detecting
SQL injection and the cost of implementation for each.
Key Words: SQL lnjection, SQLRand, Detection based on decision Tree,
Evaluation
VIII
, Indice de tablas
1 Lista de atributos y medidas elegidos para la clasificación
2 Promedio de ataques bloqueados efectivamente con la técnica de
SQLrand . ..
3 Resultados descriptivos en las pruebas de SQLRand.
4. Resultados descriptivos en las pruebas de SQLRand distribuido
por la cantidad de tiempo para el cambio de la llave.
5_ Porcentaje de éxitos en árboles de decisión, de acuerdo a la porción
de los datos utilizada para entrenamiento. . .
6. Resultados descriptivos agrupados por cada variable del árbol de
decisión creado para la clasificación de los datos. . . . . . .
33
43
44
44
46
47
7 Matriz de confusión obtenida por el proceso de clasificación en Weka. 47
8_ Lista de atributos y medidas elegidos para la clasificación . . . . 49
9. Variabilidad de los datos en cada una de las técnicas evaluadas. 54
10. Promedio de tiempo para las operaciones de SQL Rand 55
11. Tiempos para el proceso de obtener los atributos de cada consulta
SQL, para generar la entrada de Weka. . . 59
IX
, Indice de figuras
l. Ejemplo de inyección SQL en el condicional de la consulta, provo-
cando que el resultado cambie para retornar siempre en verdadero. 7
2. Ejemplo de consulta con unión de segmentos, utilizando la palabra
UNION, haciendo que la consulta sea ejecutada como una sola. 7
3 Ejemplo de sentencias anidadas, para lo cual se introduce un punto
y coma, comenzando posteriormente con una nueva sentencia. . 8
4. Ejemplo donde se fuerzan errores lógicos al convertir valores entre
tipos de datos incompatibles, para provocar errores en la base de
datos destino.
5. Descripción de error mostrado por un motor de base de datos SQL
8
al realizar una conversión de datos no permitida o incorrecta. 9
6. Ejemplo de inyección de código en un procedimiento almacenado,
el cual ejecuta código dinámico en su interior. . .
7. Inyección de código para la evaluación de resultados de verdadero
o falso, con el fin de evaluar el comportamiento de la aplicación
9
vulnerable al recibir errores desde la base de datos. . . . . . . . . 10
8 Sentencia elaborada para ejecutar tiempos de espera en el servi
dor, evaluando comportamiento al introducir mayores tiempos de
espera en la ej ecución. .
9. Cambios en la codificación de los textos para ejecución de consultas
maliciosas, realizando cambios en los caracteres finales que ingresan
al motor de base de datos.
10. Arquitectura básica de SQLRand, en la que se muestra el flujo de
comunicación entre los componentes. .
11. Ejemplo de consulta aleatorizada con una frase clave en las pala
bras reservadas del lenguaje. .
12. Consulta traducida posterior al ingreso de parámet ros por parte
del usuario.
13. Arquitectura general del proceso de procesamiento y clasificación
de consultas por medio de un árbol de decisión.
X
11
12
14
15
16
17
14. Arquitectura general del proceso de comunicación con WCF, toma-
da de http://www.ezzylearning.com/tutorial/programming-wcf-services 20
15. Pantalla principal de la herramienta Weka 3.8. 21
16. Pantalla de explorador de weka en su versión 3.8 con un archivo
de texto preparado para análisis. . . . . . . . . 21
17. Línea de comando presentada al ejecutar la herramienta SQUviap
para el análisis de una aplicación. . . . . . . . 23
18. Datos de sa.Iida generados por SQLMap al verificar el motor de
base de datos y obtener las tablas la componen.
19. Ejemplo de pantalla utilizada por la aplicación para la interacción
e intercambio de datos con la base de datos.
20. Ejemplo de consulta enviada por la aplicación, con el fin de obtener
23
25
datos filtrados por el identificador del cliente. 26
21. Ejemplo de consulta con un segmento de código inyectado por un
atacante, donde se provoca que la evaluación de la condición resulte
verdadero. . . . . . . . 26
22. Arquitectura para la implementación del modelo basado en la so-
lución con árboles de decisión. . . . . . . . . . . . 31
23. Ejemplo de pantalla desarrollada para la aplicación vulnerable uti-
lizada. . .... 34
24. Ejemplo de concatenación de cadenas, utilizado por la aplicación
vulnerable para el manejo de las consultas SQL. 35
25. Archivo de configuración de la aplicación vulnerable, de forma que
permita almacenar las consultas en distintos archivos de texto. 35
26. Ejemplo de líneas de comando utilizadas para el llamado a SQLmap 36
27. Formato de archivo procesado por Weka para generar un árbol de
28.
29.
30.
decisión . ... .
Histograma de frecuencias en los resultados de SQLRa.nd . .
38
45
Estructura del árbol generado para todos los atributos seleccionados. 48
Estructura del árbol generado para todos los atributos seleccionados. 48
31. Promedios por cada atributo de tipo numérico. . 50
32. Distribución de las sentencias de acuerdo al tipo de consulta. 51
XI
33. Clasificación de consultas de acuerdo al contenido de comentarios. 51
34. Clasificación de consultas de acuerdo al contenido de comentarios. 52
35. Dispersión de los datos en los resultados de ambas técnicas evaluadas. 53
36. Promedio de mili segundos por consulta en la extracción de los
atributos. 56
XII
l. INTRODUCCIÓN
Los ataques de inyección de código en alto nivel (por ejemplo código Shell),
están reconocidos como el principal riesgo de seguridad que sufren las aplicaciones
expuestas a través de los entornos web [7]. Las aplicaciones web, al ser ubicuas,
tienen la ventaja de estar disponibles para todo tipo de usuarios y en cualquier
lugar que mantenga una conexión a Internet. Esta disponibilidad también hace
que las aplicaciones sean vulnerables o que estén expuestas a usuarios maliciosos,
quienes pueden tratar de acceder o causai· daños en cualquier momento. Las
inyecciones de código en aplicaciones web se realizan usualmente mediante los
datos de entrada, al ingresar segmentos de código malicioso, con la intención
de generar algún daño, o bien obtener información sensible que no debe estar
disponible a través de la aplicación.
Johari y Sharma [20], definen una clasificación para las inyecciones de código
de alto nivel en: 1 Comandos cruzados de Sitio(XSS), 2- Inyecciones de XML
(XPath), 3- Inyecóón de código interpretado {Shell) , 4- Inyección de código SQL.
Las inyecciones de código SQL, son una técnica de ataque que tiene como objetivo
aplicaciones que se encuentran conectadas a una base de datos. Como resultado
de un ataque de inyección SQL, el atacante puede obtener acceso a la información
sensible de la compañía, o de igual forma podría lograr incluso realizar cambios
a la estructura o a los datos, causando pérdidas importantes y sensibles, lo que
podría resultar siendo una pérdida significativa. Tal y como se menciona en el
título de este trabajo, el alcance de la evaluación se realizó con inyecciones <le
código SQL únicamente.
De acuerdo con lo mostrado por Kumar y Pateriya en [26], existen diversos
tipos de propuestas para mitigar ataques de inyección SQL. Las distintas técnicas
se pueden clasificar según su objetivo principal en: Herramientas para la detección.
prevención o para ambas funciones a la vez.
Las herramientas de detección [12, 24, 30, 40, 41] están orientadas a reconocer
eventos que son activados cuando se presentan patrones que se consideran dis
tintos a los conocidos (por ejemplo un número anormalmente alto en la cantidad
de condiciones para filtrado de la consulta). Al identificar un evento considera.do
2
anormal, este se excluye de la solicitud para que no sea procesado por la base de
datos y poder ser analizado posteriormente.
Las herramientas de prevención [8, 10, 13, 23, 31] tienen el objetivo de analizar
el código fuente, consultas u otros puntos de las aplicaciones con el fin de detectar
omisiones o fallas que pueden resultar en una vulnerabilidad estas técnicas están
basadas principalmente en revisiones guiadas por el empleo de metodologías de
desarrollo como lo son las buenas prácticas [6, 22, 28], o basados en el estudio
de un historial de inyecciones registradas previamente las cuales son agregadas
como parte de la revisión del código fuente [28] antes de ser publicado para su
funcionamiento en ambientes de producción.
Finalmente, existen herramientas creadas para cubrir tanto la función de pre
vención, como la de detección [11, 14, 15, 17, 19, 29, 33- 35]. Estas contienen me
canismos que realizan revisiones a los datos de entrada del usuario y a su vez
ejecutan un análisis sobre la consulta que se pretende enviar a la base de da
tos, para verificar que no se hayan introducido datos que contengan inyección de
código.
La evaluación realizada en este trabajo utiliza dos técnicas de detección para
ataques de inyección SQL, con metodologías de aplicación muy distintas. Ambas
técnicas están fundamentadas en análisis dinámico de la entrada de datos, es de
cir que el análisis se realiza durante el tiempo de ejecución de la aplicación. Las
herramientas utilizadas son SQLRand propuesto por Stephen Boyd y Angelos Ke
romytis en [11] y Detección por árboles de decisión propuesto por B. Hanmanthu,
Raghu Ram y P. Niranjan [18].
SQLR.and [11] permite evitar la ejecución de sentencias SQL que contengan
código malicioso, utilizando un proxy que genera llaves aleatorias, las cuales se
adjuntan a las palabras claves del lenguaje SQL. De esta forma, cuando un ata
ctinte introduce código malicioso, el cual no es parte de la consulta original, este
no contiene dichas secuencias por lo que será detectado y se evitará que sea eje
cutado en la base de datos. La funcionalidad principal del proxy, además de ser
el encargado de la traducción de las consultas, es llevar el control del tiempo de
validez de cada llave generada, de forma que por rangos de tiempo determinados
el algoritmo genere una nueva llave de aleatorización.
La llave utilizada, puede ser tan grande o compleja como se desee, por lo que
un atacante podría necesitar mucho tiempo y capacidad de procesanüento si el
objetivo es poder obtener la llave y realizar ataques de inyección.
La evaluación llevada a cabo está basada en determinar el porcentaje de efec
tividad que tendrá la técnica, tomando en cuenta que estará cambiando dinámi
camente su llave de diversificación en intervalos de tiempo definidos, para evitar
ser víctima de inyección SQL aún cuando exista un atacante que logre obtener
una llave y producir consultas maliciosas.
La técnica basada en árboles de decisión [18] está orientada a la clasificación de
una serie de consultas, basándose en la estructura de las mismas o en los atributos
que éstas contienen, utilizando un conjunto de propiedades previamente definidas ,
lo cual alimentará una estructura de árbol y será el insumo que permitirá tomar
las decisiones necesarias para determinar si la consulta candidata contiene o no
una inyección de código, y de esta forma impedir que sea ejecutada en la base de
datos.
En la evaluación para la técnica de árboles de decisión [18], se comprobó el
porcentaje de efectividad que se obtiene al clasificar uno o más grupos de consultas
para verificar si contienen inyección de código o no. Para ambas metodologías;
las consultas fueron obtenidas usando una herramienta real de inyección SQL,
SQLMap [39].
Se utilizaron consultas SQL con y sin inyección para evaluar ambos métodos y
asegurar que el árbol pueda utilizar un porcentaje de las consultas para el apren
dizaje y el restante para la clasificación necesaria.
El objetivo originalmente propuesto, se presenta en la subsección 1.1, a con
tinuación.
1.1. Objetivo
Realizar una. evaluación de dos técnicas de defensa contra ataques de
inyección SQL, con el propósito de medir el impacto que ocasiona su
uso en términos de seguridad y tiempos de respuesta, en el contexto
de una aplicación web específica.
4
La justificación de la escogencia del objetivo se detalla en la subsección 1.2
presentada a continuación.
1.2. Justificación
Existen distintas propuestas para detectar y evitar los ataques de inyección
SQL, sin embargo durante la revisión de literatura realizada, no se encontra
ron trabajos en los que se comparen dichas técnicas en términos de seguridad y
rendimiento obtenido al ser implementadas en una aplicación.
En la siguiente subsección se trata sobre los alcances del presente trabajo.
1.3. Alcances
Dentro de las limitaciones que se identificaron durante el desarrollo de este
trabajo, se resalta principalmente, la dificultad. para poder adivinar de una forma
más real la llave de aleatorización utilizada por la defensa, por lo que se recurre
a un mecanismo de "simulación de robo" para poder utilizar la llave desde la
herramienta de ataques y poder así medir la cantidad de ataques exitosos que se
podrían lograr.
Durante los ataques ejecutados en las pruebas de SQLRand [11], los tiempos de
ataque, no fueron sincronizados con los intervalos en los que se generan las llaves
aleatorias, lo que puede significar que algunos ataques, aunque logren obtener el
acceso, la ventana de tiempo disponible para el ataque pueda ser muy breve, de
esta forma puede ser que se obtenga un alto porcentaje de éxito en la evaluación
de la metodología, ya que la mayoría de los ataques de cada intervalo serían
fallidos.
5
El resto de este documento se organiza de la siguiente forma: La sección 2, des
cribe el marco teórico, referencias y descripciones sobre conceptos y herramientas
utilizadas en este trabajo, Sección 3 relata la metodología para la implementación
y pruebas de cada modelo propuesto. Algunos problemas previstos y limitaciones
enfrentadas durante el desarrollo de este trabajo se presentan en la sección 4. En
las secciones 5 y 6 se presentan los resultados obtenidos y tiempos de respuesta
por cada uno de los modelos, mientras que las conclusiones y el trabajo futuro se
presentan en las secciones 7 y 8.
l t
2. MARCO TEÓRICO
En la sección del marco teórico, se consideró importante hacer una introduc
ción a lo que son las técnicas conocidas de inyección SQL y algunos ejemplos de
cómo se realiza cada una, además de incluir todos los conceptos, herramientas y
algoritmos que son utilizados directamente en la elaboración de este trabajo, con
el fin de brindar una mejor contextualización y entendimiento. El marco t eórico
está organizado en las siguientes secciones: 3.1 Técnicas de inyección de código
SQL, 3.2 Defensas propuestas, 3.3 Herramientas utilizadas, 3.4 Herramientas para
pruebas de ataques de inyección SQL.
2.1. Técnicas de inyección de código SQL
En el ámbito de SQL, existen técnicas conocidas [16], que son utilizadas por
herramientas automatizadas, para generar ataques hacia aplicaciones o servidores
de bases de datos. Dentro de las técnicas de inyección de SQL [16], se mencionan:
"Tautologías" , "Unión de consultas", "Combinación de est atutos", "Sentencias
incorrectas lógicamente" , "Procedimientos almacenados", "Inferencias" , "Codifi
caciones alternas"
2.1.1. Tautologías
Se basa principalmente en la inyección de código en estatutos de condición,
para poder obtener siempre un resultado positivo en la condición y de esa forma
pasar la seguridad u obtener los datos requeridos. Dentro de los usos más comunes,
de esta técnica, se encuentra el paso de mecanismos de seguridad, además de
extracción de datos, utilizando como punto de ataque la cláusula "\iVhere" del
estatuto SQL. En la Figura 1 se muestra un ejemplo de código SQL con una
inyección en el condicional.
7
SELECT acco:..::-:.cs
FROM ~se~s WHERE loQi~•'' or - - - ANO pass•'' ANO pin-
Figura 1: Ejemplo de inyección SQL en el condicional de la consulta, provocando que el resultado cambie para retornar siempre en verdadero.
2.1.2. Unión de Consultas
Este tipo de inyección, se utiliza principalmente para la extracción de datos
de tablas distintas a las que originalmente se han utilizado en la consulta, para
enviar un ataque de unión, se utiliza algún parámetro vulnerable para cambiar
su valor por una consulta específica, que retorne los datos que se necesitan. En
la Figura 2 se muestra un ejemplo de código en el cual se inyecta una segunda
consulta por parte del atacante.
SELECT acco~:-.t:s
~ROH ~sers WHERE loQi:-- ••
UNION
SIU.BCT cardNo rrom Credl.tCards wbere acctNo• .
Figura 2: Ejemplo de consulta con umon de segmentos, utilizando la palabra UNION, haciendo que la consulta sea ejecutada como una sola.
2.1.3. Combinación de estatutos
Son ataques que están orientados a realizar una acción en la base de datos,
no solo extracción de datos, sino, provocar daños en la estructura de datos y
hasta lograr detener el servicio. Principalmente, la técnica utiliza sentencias adi
cionales a la original, que tienen como objetivo inserción de datos o creación de
procedimientos almacenados, que pueden ser utilizados posteriormente en otros
ataques.
SELECT acco:.nts
FR<»l u.sers WBERE loc;ri.n• 'doe• ANO ¡;:a!!!!• '' ; drop table :.:. !!e=!! -- ' ; ... m::: ¡::.;. • - - !
Figura 3: Ejemplo de sentencias anidadas, para lo cual se introduce un punto y coma, comenzando posteriormente con una nueva sentencia.
En la Figura 3, se muestra un ejemplo código que contiene un segmento de
inyección, la cual utiliza como delimitador el punto y coma ";" lo cual hace que
la segunda parte del código contenga una sentencia para eliminar la tabla users,
provocando un daño en la formación va.liosa para el sistema.
2.1.4. Sentencias incorrectas lógicamente
Este tipo de ataques, es considerado el preliminar de otros ataques, ya que
está diseñado para obtener información importante sobre la estructura de la base
de datos que se desea atacar. La principal vulnerabilidad asociada a este tipo
de ataques, está relacionada con la página general de error que se utiliza en
los sistemas web, donde normalmente se muestra mucha información sobre las
excepciones generadas en la aplicación. Los errores generados por el sistema,
pueden revelar información importante para el atacante, como los nombres de
tablas, campos o incluso parámetros que pueden ser vulnerables a un ataque
predeterminado.
SELECT a.cc=:.:::-.t:~
f'ROH ·~~e.:::~
WHl'!RE :.oc;l.::- '' ANO ¡:a.~~= · ' ANO ¡::i::- convert ( int, (se1ect eop name
t'roa sysob:)eces where xeype- 'u') )
Figura 4: Ejemplo donde se fuerzan errores lógicos al convertir valores entre tipos de datos incompatibles, para provocar errores en la base de datos destino.
En la Figura 4, se muestra un conjunto de instrucciones que pretende inyectar
9
una operación que resulte en un error lógico, el cual será devuelto en una excepción
del motor de base de datos, como la que se muestra en la Figura 5.
"Ml.crosoft OLE DB Provider fer SQL Server (0x!!0040!01) Error eonverting nvarchar value 'CreditCard.9' to a colwr..'l of da.i::a. i::;o::~ ::.::-.i::. "
Figura 5: Descripción de error mostrado por un motor de base de datos SQL al realizar una conversión de datos no permitida o incorrecta.
El mensaje de error que se muestra en la Figura 5, revela dos importantes
datos, primero se muestra que el motor de base de datos que se está utilizando
es Microsoft SQL Server @, adicionalmente, se muestra el valor del texto que se
está tratando de convertir a un valor entero "CreditCards" , el cual corresponde
al nombre de una tabla del modelo. De esta forma, el atacante puede obtener más
datos del modelo y crear ataques futuros.
2.1.5. Procedimientos almacenados
Generalmente, este tipo de ataques, tiene como objetivo la ejecución de pro
cedimientos almacenados, principalmente los que son provistos por el motor de
base de datos, los cuales brindan funcionalidades específicas, como pueden ser
interacciones con el sistema operativo, o modificación de las credenciales de un
usuario en específico.
CREATE PROCEDURE OBO isAuthenticated @userr~ame varchar;, 50 • @pass varchar~ 59) AS
EXEC 1 'SELECT * FROM dbo . dual WHERE Id_dual= ' ' ' •@userName ; ' ' ' and Id_Dual=' • ' @pass '1;
exec DBO isAuthenticated '222' . '11''; select * from sys.sql_modules'
Figura 6: Ejemplo de inyección de código en un procedimiento almacenado, el cual ejecuta código dinámico en su interior.
En el ejemplo de la Figura 6, al ejecutar el procedimiento almacenado, se rea
liza la ejecución de la primera sentencia, y posteriormente se ejecuta el comando
10
select * from sys. sql_modules lo cual hará que el procedimiento devuelva
datos que el atacante desea conocer.
2.1.6. Inferencias
Este tipo de ataques se utiliza para poder inyectar código en aplicaciones que
han sido aseguradas y que no brindan información detallada sobre los errores
obtenidos en la ejecución de código SQL, En estos casos, el atacante inyecta
código en el sitio y realiza un monitoreo cuidadoso para determinar cuándo el
comportamiento de la aplicación cambia, y de esta forma poder inferir valores de
campos o tablas, sino también algún parámetro que sea vulnerable. Existen dos
técnicas conocidas, que son basadas en inferencia.
• Inyección a ciegas
En esta técnica, se realizan intentos de inyección para introducir cláusulas
de tipo verdadero/falso. Incluso si no hay retroalimentación de errores, sí el
segmento de código se ejecuta correctamente, la página continuará función
normal, pero sino, entonces el comportamiento de la aplicación será distin
to. Por ejemplo: en la Figura 7, se muestran dos consultas, en la primera
de ellas, se envía una expresión que al evaluarla devuelve un resultado ne
gativo, por lo que en términos de la aplicación, se devolverá un mensaje de
error, incluso cuando el mensaje no sea descriptivo como para poder inferir
valores importantes. En la segunda consulta, se envía una expresión que al
evaluarla, se obtiene un resultado positivo, por lo que, al ser ejecutada se
lograría pasar la pantalla de autenticación sin recibir el mensaje de error,
que se obtenía en la primera consulta; de esta forma, el atacante sabrá que
la inyección de código fue exitosa y que el parámetro utilizado es vulnerable.
Figura 7: Inyección de código para la evaluación de resultados de verdadero o falso, con el fin de evaluar el comportamiento de la aplicación vulnerable al recibir errores desde la base de datos.
11
• Ataques por tiempo
Esta técnica, permite al atacante obtener alguna información, mediante el
monitoreo del comportamiento en el sistema, al introducir sentencias que
generen algún tipo de espera en la respuesta para la respuesta de la base
de datos. Considerando la Figura 8, el código utilizado trata de analizar la
primera letra de la primera tabla en el modelo, la cual se compara contra
un valor de X. Mediante el envío de una serie de consultas similares, el
atacante puede conocer cuándo se cumple la condición evaluada, debido al
monitoreo en el tiempo de respuesta del servidor.
SEU!:CT accounca !'ROM ~aera WBERE loqin- 'leqa l Uaer' and ASCII (SUBSTRINO ((select cop name trom aysobjecca) , , ))
> X WA i tFOR
Figura 8: Sentencia elaborada para ejecutar tiempos de espera en el servidor, evaluando comportamiento al introducir mayores tiempos de espera en la ejecución.
2 .1. 7. Codificaciones alternativas
En esta técnica, se utilizan distintos codificadores, para tratar de generar sen
tencias que no tengan significado a nivel de la aplicación, pero que si afecten
o tengan una semántica a nivel de la base de datos. Por ejemplo, la expresión
char(120) a nivel del aplicativo puede no tener un significado especial, pero al
llegar a la base de datos, puede ser ejecutado y generar un símbolo x. Normal
mente esta técnica se utiliza en conjunto con otras, ya que por sí sola, cambiar
codificaciones no provee una forma de atacar una aplicación, sino que la técnica
puede ayudar a evitar mecanismos de prevención y explotar vulnerabilidades. Pa
ra un desarrollador, es muy difícil implementar técnicas de defensa contra ataques
de alternación de codificación, puesto que tendrían que conocer todas las posibles
codificaciones que podrían afect ar una cadena de caracteres.
SELECT a::c=:.:.::t-' FROM t: -'e:::"-' WHERE ! oq.:..::=' :..e.;a:..:J-'e:::' ;
exec (char ( x-36= 7 5~~6~6f~~6e)) -- ~lD ~a~~· · • .k..~D ~~~r
Figura 9: Cambios en la codificación de los textos para ejecución de consultas maliciosas, realizando cambios en los caracteres finales que ingresan al motor de base de datos.
En la Figura 9, se muestra una consulta que utiliza un comando char() con un
valor codificado en hexadecimal, el cual contiene la codificación para el comando
SHUTDOWN, por lo que, al ejecutar el valor en la base de datos, se ejecutará el
comando mencionado y la base de datos quedará fuera de servicio.
2.2. Defensas evaluadas
En el desarrollo de este trabajo, se evaluaron dos metodologías contra ataques
de inyección SQL: SQLRand descrita en la sección 2.2.1 y Detección basada en
árboles de decisión que se describe en la sección 2.2.2
2.2.1. SQLRand
SQLRand [11] es un conjunto de funcionalidades expuestas a través de un
proxy, las cuales brindan la facilidad de diversificar consultas SQL, ya que per
mite la comunicación desde y hacia la base de datos, funcionando como el inter
mediario entre estos dos componentes en todo el proceso de comunicación.
El mecanismo de diversificación se da mediante la generación de una llave
aleatoria, misma que es adherida a las palabras claves del lenguaje de base de
datos, antes de que la consulta sea mezclada con los datos que son ingresados por
el usuario. Al introducir los datos de usuario y ponerlos junto con la consulta,
las palabras clave de SQL que pudieron haber sido introducidas por el atacante
quedan sin aleatorizar, por lo que son detectadas rápidamente y rechazadas antes
de que se envíe la consulta a la base de datos.
13
Lo más importante de la llave de alecttorización, es qut> esta debe cambiar
const.ant.<>m<>nte para evitar que• si un atacante• ohtieu<' <>l <lato, e•:-;t<' pn<>da hacN
uso y evadir el mecanismo de defensa. El problema con <>l tiempo de cambio para
la llave. es el impacto que puede significar para la o las aplicaciones cliente que
c::;tén conectada:; y haciendo uso <lcl proxy, ~·a que si una aµlit:adón no está coor
dinada con Ja llave coi-recta . se rechazarán todas las consultas em·iadas por esta.
2.2.1.1. Arquitectura del modelo en SQLRand
El lll<>canismo <le SQLR aucl [ 11] está ha.<inclo en uu e·omponcnte prindpaL rlr
nominado proxy, el cual realiza la aleatorización de las consultas que utilizará Ja
aplicación previo a la interaedón eon la base de da.tos. El proceso de diversifica
ción, se lleva a caho utilizan<lo una fütv<' <linámica, la mal debe adjuntars<' <'ll la..,
palabras clave del lenguaje SQL antes de que la consulta sea unida con los datos
de introducción del usuario, y así poder distinguir entre las palabras del lengua.je
pertenecientes a Ja. commlta y las que fueron iug,rcsa<las por mc<lio <le los <la.t vs
del usuario.
La consulta. que fue alcatorizada, debe volver a In forma original cuando se
e1wía al proxy previo a la ejecución contra la ha.'it> <lt> datos. <>I prox~· dehe cono
cer la llave dinámiea para pod<>r formar la consulta original de forma correcta y
ejecutarla contra la base <le datos.
El aspecto más importante de la llave dinámic-a es, que debe ser volátil ~'
n1mbiar con algún periodo <le t.iempo definido, por lo rn<'l. esta coordinación
pn<>d<' af<>ct.ar la aplicación qu<' Cf' cli<>nt.<> <l<>l proxy. por <'lHk, r<>chazar todas la."
consulta.<; enviadas por la aplicación, aun f'Uando esta." sean correctas.
En l<l figura 10 se muestrn Ja comunicación báskél ck SQLRand con los puntos
ele i111<-rnn:ió11 que compom·n la metodología.
14
ApNcac lón citen ten
A¡llcedón diente 1
..... Base de Delos
Figura 10: Arquitt>ct 11rn básica de SQLHaud. 1•11 la que se 111uestra el flujo de comunicación entre los <·1>111punentt's.
Proxy
La solución que se plantea en SQLRand [ 11 j. brinda un proxy, ene-argado de
la aleatorización de consultas SQL: para esto. :se identifican las palabra.-; eh\\'es
del lenguaje y se le::- agrega una llave aleatoria que 110 sea fádlrnentt' adivinable
por el atacante. Lo anterior significa que. el lenguaje adoptaría nuevas palabras
rt->st>n·ada.-; que no p11edt->n ser rec·onudda::; por el motor de ba."le de datos.
De la misma fur111a. ~· utilizando la llave al111a('e11ada en memoria en el 1110-
mento, el proxy delw ser eapaz de tomar una consulta aleatorizada y traducirla
a su forma original. para que sea procesada. y retorne los datos solicitados por la
aplicación.
El servicio brindado por el proxy. se lleva a cabo de forma extt->nJa. lo que
significa que el proxy no es dependie11te de la aplicad<)n que lo consuma. per
mitiendo que se mantengan varias aplil'acio1ws haciendo uso de un mismo proxy
para la comunicación C'Ull la base de datos.
15
Debido a lo antes mencionado, es de suma importancia que la coordi11ació11
entre las distintas aplkadones y el proxy esté c·orre<'ta. y que la llave utilizada
para aleatorizar la consulta sea la misma que se utiliza para traducirla a su forma
original.
lJ na solución que resultaría muy difícil de implementar podría ser modificar
d i11térprete de base de datos, para poder comprender ,. procesar las palabras
clave; lo cual puede resultar confuso y represe11tar un arduo trabajo. ademá..., de
que rápidamente sería 1111 hecho que se cono<"ería y dejaría de representar una
técnica de seguridad para c·om·ertirse e11 u11 lenguaje est<indar.
La Figura 11 ilustra el con<"epto de aleatorizaci1)n de se11t.e11das SQL, segú11 el
ejemplo. en la secció11 anterior, posterior al procesado y agregado del identificador
aleatorio a las palabras daves del lenguaje.
SELECT123456789 Cedula Nombre Prlmer_Apellldo Sequndo_Apellldo FRON123456789 dbo Cliente WHERE123456789 Cliente Id Cliente SID_CLIENTq
Figura 11: Ejemplo di· co11s11l1 a aleatorizada co11 lllm frmw davc t'll las pala liras reserradas del lenguaje.
La consulta mostrada Pll la Figura 11 deberá ser pro<"esada por el prox.\'.
para qu<' sea trascrita nuevamente a un formato comprensible. justo a11lt's de ser
ejecutada y retornar los rc>sultados de la mbma.
Cuando una consulta es inyectada c·ou u11 segmento de código ilegal. y se
solicita al proxy que realice la traducdón al le11guaje SQL. se ejecuta previamente
una aleatorizaeión con una llave distinta. la c·ual hace que al eliminar la llave de
utilizada para diven;ifiC'ar la sentencia original. t>I código inyef'tado no pueda ser
eje<·utado por la base de datos. Si se utiliza el ejemplo mostrado en la Figura
11. ~· se inyecta el segmento de C'ódigo J 2 OR J ~ J en el valor de In rnriable
ID CLIENTE, una \·ez que el código SQL sea traducido por el proxy. quedaría
según se muestra en la Figura 12.
l'ROM1234S67U cSbo.CLitllTE
.. ::iS.l .. : .Jti--
S!L!CT :rnuu. ll:lMBR!:' PRIMER_APtLLIDO. SEGONDO_llPELLIOO
rRC»4 c11>~.~LttllTE
~ tgura 12: Consulta traducida posterior al ingreso de parámetros por parte del usuario.
La consulta mostrada en la Figura 11, deberá ser procesada por el proxy,
para que sea transcrita nuevamente a un formato comprensible, justo antes de
ser ejecutada y retornar k>.:i resultados de la misma.
2.2.2. Detección de inyección SQL basado en árboles de decisión
Los árboles ele decisión j 18] son una técniea conocida de minería de datos. qut:>
utiliza estructuras t:>ll forma de árbol, lo que Je permitt> ejecutar clasifieaciunt:>s y
toma de decisiones. basadas en los costos o relt:>\'anda generada en cada uno de
sus arcos y determinar. de esa forma. los datos más significativos que se deben
tomar en cuenta a la hora de la toma de decisiones. Los árboles de decisión son
comúnmente utilizados en minería de datos. con el fin de realizar dasificadones
basadas en una serie de atributos pre establecidos, estos atributos se representan
en forma de nodos. ~· eada posibilidad de salida del nudo, representa el punto del
valor que hará la diferencia en el paso siguit-'nle.
2.2.2.1. Arquitectura del modelo en Árboles de decisión
El modelo de arquitectura para la solución basada en árboles de decisión. se
fundamenta en el aprendizaje del árbol para poder conocer diferentes consultas,
tanto con inyección de SQL como rnrnsultas correctamente formuladas y sintácti
camente buena.o.;. que puedan ser ejecutadas contra la base de datos sin problema.
17
Lo anterior, hace que el modelo deba contener consultas C'on inyecdón y sin
inyeceión para que pueda obtener el aprc>ndizaje necesario y lograr dasifkar los
datos de entrada una vez red hielos.
El árbol de decisión debe redbir un archivo rnn la lista de atributos pertene
cientes a cada consulta almacenada. t'8tos atributos deben ser generados ya sea
manual o automfü ieamente para que sean utilizados en la clasifkad<Íll, por lo
que el archivo resultante es introducido al árbol parn la creación de árbol y el
<·lfiliifi<-ador correspo11die11te.
En la figura I:l se muestra el flujo de arquite<"turn general. utilizado en el
proC'eso <le clfiliifkación por medio del árbol.
Consultas
Ktura
\ (
- ( ,. ~~ Procesador consultas
Escritura
.... x:: ------csv
Atributos
---4'roceumiento-+
Arbol de decisión
~lasificación--+
Resultados
Figma U: An¡uitet't urn g1·1wral dl'I procl'so de proC'esamiento y dasilicadún <le C'Onsultas por medio de un árbol de decisión.
E11 su versión :u~ weka pres1•nta y n-'(·omienda utilizar el algoritmo J48 cuando
se trata de árboles de dedsiún. sin embargo. existen ademá.-; otros algoritlllos base
18
o implementaciones para la utilización con árboles de decisión, tales como ID3,
C'.4.5 y .148.
2.2.2.2. 103
Iterative Dichotomiser 3 [37] (ID3) por sus siglas en inglés. es un algoritmo
inventado por Ross Qui11la11, el c:ual es utilizado para generar uu árbol de deci
sión utilizando un conjunto de datos. ID3 es típicamente utilizado en procesos
de aprendizaje de maquina y procesamiento de lenguaje natural. En general, el
algoritmo se basa eu los siguientes pasos para la comstrucción del árbol:
• Calcular la entropía de cada atributo utilizando el conjunto de datos.
• Separar el conjunto de datos utilizando el atributo y su información de
ganancia o entropía.
• Crear un nodo de árbol con el atributo seleccionado.
• Repetir el proceso recursiva.mente con los atributos restantes.
2.2.2.3. C4.5
C4.5 [25] es un algoritmo utilizado para la generación de árboles de decisión,
es una extensión del conocido algoritmo ID3, conteniendo algunas mejoras. Los
árboles gcucrn<l08 por el algoritmo C-1.5 pueden ser utilizados para dcusificación,
por esta razón, el algoritmo algunas veces t>s rt>ferenciado como nn cla.<iifica<lor
estadístico. C4.5 fue posicionado como el número 1 del top 10 en algoritmos de
minería de datos, esto al ser publicado por Springer Lecture Notes in Computer
Sdence (LNC'S). Los pa.<;os básicos para la creación <le árhol<'s, utilizados por C4.5
se mencionan a continuación:
• Calcular la c•ut rnpía de cada atributo utilizau<lo el conjuuto <le <latos.
• Elegir nu atributo ·· a" cou d mejor nilor <le gmmm:ia.
• Crl'ar un nodo que parta del atributo seleccionado como ·· c1.".
19
• Recorrer los nodos rcst antes agregándolos como hijos del nodo "a ...
2.2.2.4. J48
J.18 [1] es una implementación del algoritmo C.1.5 [2.5] en el lenguaje Java [5] .
realizado por el equipo de \Veka [4], para su utilización en procesos de :Minería
de Dat.Ol:i.
2.3. Herrainientas utilizadas
Para la implementación y evaluación de este trabajo, se utilizaron herrnmien
ta:s c¡ue permitiernn la mat crialización <le lo:s coucept.o:s prcsc11ta<lo::1 en nula una
dP las técnicas. El criterio para la clc•ccióu <le las herrnmie11tas utilizadas princi
palmente fue la familiaridad con las mismas, lo cual permite reducir el tiempo
<le desarrollo y configuración, aun así, es posible que eu una futura evaluadón
por parte de un lector, se pn<'dcn elegir distintas t<'cnología." para llevar a caho
la arquitectura mostrada.
2.3.1. Comunicación entre máquinas
\Vindows Conununication Foundation [32j, es una arquitectura que provee
l\licrosoft, el cual permite la creación de sistemas o componentes orientados a
servidos, WCF !32] permite n<·ar comunicaciones con servicios que puc<lcu estar
publicados tanto eu un servidor de aplicaciones como en servidos de ~licrosoft
\Vindows R . \VCF [32] permite a<lemás, la c·onumicaciún entre puntos utilizando
<liforcutes protocolos para d intcn:ambio <le <lato:s, pcrmiticn<lo así uu cst,\11<l1:1r
de c01mmicadones c•ntre lo.-. servicios y la." distintas plataformas y sist.ema.<; opP
rativos, ya que permite el uso de formatos binarios, X:\IL. entre otros.
En la figura 1 1 sr 11mcstra la arqnitcctnra luí.-.ica clcl pro<·<•so <l<' (·01111micación
1•11tre máquina:; ntilizan<lo los :-;ervicios <le WCF, los males permiten la <lefiuición
de puntos ~- metoclologías <le int errnmbio de datos. <ldemt\s de resaltar un archivo
20
de configuración del :-wrvkio y un archivo \VSDL .,¡ c·unl <·011tie11P los métodos o
contrato entre lo:-; s1,n·icios que intPract1ía11.
Figma 14: Arquit <•c·t ura general del proceso de c·omunicacióu con \VCF. tol!lada de ht tp: / /www .t'zZ_\'lt'arning.com/tutorial / prograuuning-wcf-services
2.:J.2. Weka
Para implementar el l!létodo de deteeción con árboles de decisión [ 18[. se uti
lizó Weka [4). Weka [4] es una herramienta para minería de datos, desarrollada
eu la Universidad dt> \Vaikato, que contiene una colección de algoritmos para
aprendizaje de máquina. que permiten el procesamiento y clru;ificación de distin
tru; fuentt>s de datos. La versión utilizada fue Weka 3.8 ¡4] para el proeesarnie11to
y la dasifieaei6n del set de datos obtenido.
\Veka ofrece una gran diversidad de herramienta." para exploración de datos.
experimentación y generaC"ión dt> couoci111ieuto. en ei;tP trabajo se utiliza la fun
cionalidad de exploración de datos, ) a que en es la que se muestra la sPcción dt>
da.'iifieación con árboles dt> decisión.
Eu la figura 15 sp muestra la pautcilla de ingreso a \Veka, lru; opciones generales
que ofrece en su versión 3.8.
22
2.3.3. SQLMap
SQLmap [39], es la herramienta qne se utilizó para generar las consultas de
ataque. Dicha herramienta provee un C'onjunto <le funcionalidades que utilizan
distinta.e; té<'nka.c; para inyecc>ión de> C'Ódigo. ha:o;ada." en tfrni<'ns d<' iny<'<'í'ión de
SQL conocidas. además de proveer soporte para la intera<'ción con los motores
de administración de base de datos má5 conocidos. En este trabajo se utilizó la
versión 1.1.1.16 <le SQLMap.
SQLmap [39], permite crear pruebas o ataques automatizados para detectar o
explotar vulnerabilidades de aplicaciones web. Estos ataques utilizan parámetros
establecidos, que pueden ser estáticos o <lim\111i('os, lo que permite que sean eje
cutados una gran cantidad de veres. para así llevar a <'abo la evaluación y control
de pruebas de una forma más práctica y simple, sin tener que realizar un trabajo
extenso para iniciar ca<la uno <le los ataques. SQLmap realiza. los ataques por
lotes, lo mal significa qH<' al C'stahlc<'<'r la dirección url de la aplicación destino, <'
iniciar los ataques, la herramienta realizará nníltiples intentos de inyección C'Outra
la aplicación hasta lograr obtener Ja infonna<'ión requerida o de igual forma. has
ta dC'terminar qn<' no <·xist<' posibilidad d<' oht<'ller información d<' la apli<'adón
víctima.
Algunos ;u;pectos importantes <le SQLl\Iap [3Ll] son que L'Sta es una herramien
ta automatizada de código abierto, desarrollada <'n el lenguaje de programacióu
Pyt.hon [3] , además ofrece funcionalidades para todas las técnicas de inyección
SQL couod<lms. SQLma.p posee conexión para <list.intos motorc'S <le bcu;cs <le <la
tos~· es co11stru1tf'mrnte nctualizada por O\YASP [2], quif'nes son los <'ncar~mlos
de su distribución.
La clist.rihndón de SQL:Map <'S con los archivos fuente. <k forma qnc· ií11ica
mente se debe <'opiar la carpeta prinfipal <'ll d repositorio destino donde se desea
ejPcutar. En la figura 17 se ohserva la vi>nlana ele eomandos que S<' lll\IPStra al
invo<'ar la hrrrn.mif'nt a SQL:\ lap c·on r) ml dr la apli<'adóu qu<' !"<' dC'sPn analizar.
Figura 17: Línea de comando presentada al ejecutar la herramienta SQLl\Jap para el análisis de una aplicación.
Parte de las salidas que presenta SQL.tdap, son algunas validaciones o C'on
finnaciones que se deben ir efectuando durante todo el proceso de análisis de la
aplicación. por lo cual es neC'esario que el usuario evaluador esté pendiente de los
resultados que se van generando. hasta que sea mostrado el resultado final por
parte de SQLl\lap. En la figura 18 se muestran los datos que son generados por
SQL.l\lap al verificar el motor y las tablas de la base de datos instalados y que se
están utilizando por una aplicación.
lff.¡cro•ott SQL. Serwr zooe fR.lM> 10.0.uoo.22 CX6•l Jul 9 2008 U;l1:U,
Ccpyn9bt ~el 19!1!1·2008 K1.cco.1ott Corporauoa f.nterpruit tdlti.on (64-blt) Oh llflndov• NT 6.1 <XU> ~Bu.1ld 1601: !erv1ce- he.le 1)
•:le 1 ( INYOJ fl.tciUtlO teblu tor dat:eb•H: s.rv1c1o•!ecr\ol091co1 r ue: Se:rvtc1o•Tecnoloq1co1
Figura 18: Datu~ dl' ::,aJ1Ja geuerados por SQLl\lap al verificar el motor de base de datos y obtener las tablas la componen.
24
, 3. METODOLOGIA
Para po<ler r<'alizar d objetivo de este proy<'cto, se comenzó por la definidón
del modelo de amenaza que se presenta en la. defensa ele ataques contra inyección
de SQL, lo que permite conocer el concepto de lo que se considera una aplicación
vulnerable a estos ataques. Ademá." s<' discuten los procC'sos d<' impl<'m<'ntadón
y ejecución, que se lleva a cabo durante la etapa de desarrollo y pruebas de cada
uno de los modelos evaluados.
Adicionalmente, se presentan las variables de respuesta a obtener para evaluar
la seguridad de cada una de las metodologías. Una vez que se tenían definidas las
variables ele respuesta, se inidó con la implementación clel modelo ele a.rquited ura
utilizarlo en carla una, tomando cu cuenta la definición descrita por los autores
de cada artículo, y haciendo uso de las tecnologías conocidas para cada uno de
los componentes.
3.1. Modelo de Amenaza
En el modelo de amenaza tanto de la técnica SQLRand [11] como de Árboles
de decisión [18], se asume que el código SQL que es utilizado por la aplicación
para realizar las op<'racion<'s <l<' l<'cturn, escritura, actualización o horrado <le los
datos, es objetivo de un atacante remoto que trata de inyectar sentencias de códi
go SQL, para alterar el comportamiento de los comandos utilizados y extraer
iufonna.dón sensible o causar claüos el la estructura <le l>asc <le elatos: o induso a
los <latos almacenados. Se asume de igual forma que las otras capas de la aplica
ción, o del sistema operatiYo, a.demás de la arquitectura de hardware que soporta
estos l'Olllpouentcs, sou seguros.
Los ataques de in:vección <le SQL que se evalúan cu este trabajo, están orien
t adrn; únicamente a las sent cnciéls de código SQL, que son ejecutadas por part P de
la aplinl<'ÍÓll contra <'l motor rl<' ha.'i<' df' datos, no así. otro tipo d<' int<'raccioncs
25
qllt' se realizan con el motor de base de datos, cowo autentieadón por seguridad
integrada, apertura o cierre de eo11exio11es. Los ataques de inyección de código
binario u otros tipos de inyección de código, estos no son contemplados en el
desarrollo de la e\'aluación de la técniea. ya que no son una defensa completa
t·ontra estos ataques.
3.2. Aplicación vulnerable
Para la verificación de las vulnerabilidades a las que se expone la aplicación
utilizada, se crearon pantallas de interacción con la base de datos. por medio de
las cuales. se intentó efectuar un ataque de inyección SQL. La aplicación utiliza
consultas que puedt'n ser vulnerables a inyección de C'ódigo, por medio de los
parámetros que se envían en cada pantalla para la interacción con la base de
datos. En la figura 19 se muestra uu ejemplo de las pantallas construida." para la
Prnluac-ión de la aplkadón vuh1erahle.
Figura 19: Ej(·111pl" 11'- p.i11t ,dl.t 111 d11.<uL1 jJul L1 ·1plll'<Wi()11 para la i11teracció11 e intercambio de datos con la ha.se de datos.
Considerando una página que muestre los datos de un diente, por medio del
identificador. similar a la presentada en la figura 19 y que se utilice una sentencia
SQL prestablecida. al em·iar los datos del identificador se ejecuta una consulta
c·omo la que se muestra en la Figura 20.
SELECT Cedula Nombre Primer_Apellido Sequndo_Apellido FRON dbo Cliente WBERE Cliente Id Cliente SID CLIENTE
26
Figura 20: Ejemplo dt> consulta t>nviada por la aplicación, con el fin de obtener datos filtrados por el identificador del dít>11te.
l'u"t eriormentt>. u11 atac·ante que dt>See iuyed ar código malído::;o, trata dt>
ingn•sar un valor no nilido en vez del idt>ntifieador del diente, dato <!lit' viajaría
dt>nt ro dt>l valor de la variable ID_CLIENTE; esto provocaría que el rt>stiltado de
la l'ollsulta C'ambie totalmente. Por ejt>mplo. si el valor dt> la variablt> ID_CLIENTE
fut>ra 1 OR l=l, según sl' 111ut•stra en la Figura 21. la forma en la que qut>daría
la l'<>nsulta. iuduyendo t>l segnwnto <le código qut> t•s im·• ·• ·t ado por el ataea.ntt>.
SELECT123456789 Cedula Nombre Primer_Apellido Segundo_Apellido FROM123456789 dbo Cliente WHERE123456789 Cliente Id Cliente 1 1 - 1
Figura 21: Ejemplo dt> mnsulta con un segmento dt> código in.wct ado por 1111
atanmtt>. donde se:> provoca que la evaluación de la condieión ft'."illlt1· ,.Nda<lt>ro.
Lo anterior prcwoca qttl' la dé1usula where i>n1líte en vt>rdadero y t>l r~ultado
rt>grese con segmidad al mt>nos un registro.
3.3. Implementación de SQLRand
Basado en la descripción dC' la arquit«:>ct ura del modt>lo. presentada t>ll 2, se
proet>dió eon la implt>mi>ntadón dt> los C'ompou«:>ntc·s 1wc·1•smios para la t>jff·udón y
e\·aluadún. seguido dt> analizar la rnriablt> dt> rt•sput>Sta qut> st> obtuvo para poder
111i>dir la se~uridad desclt> el punto dt> \"Ísta dt>seado t'll B;tt' trabajo.
3.3.1. Implementación del modelo en SQLRand
La im;taladón de los rnmpont>ntes d1• SQLR.an<l. t>l ambiente de prut>ba twc·e
sario para «:>laborar la t>rnluación reqtwrida, consistt> dt• una serit> dt> a.spt>dos qut>
si> mt>nl'ionan a c-ont i1111aeió11:
'27
l. Construcción de uua aplicación web vulnerable.
2. ConstmC'ción dC'l proxy.
3. Instalación de la base dP datos.
1. Creación <le la herramienta µara cjccudúu <le ataques.
5. Ejecución de los ataques.
Cada uno de los pasos anteriores. componP la metodología de implementación
y ejecución de técnica evaluada. Seguidamente se detalla cada uno de los pasos
<lcl µrot:cso:
l. Construcción de una aplicación web vulnerable.
SC' df'hc rf'alizar la programación o iustalar nna apliC'aC'ión hasada en una
plataforma web, la eual debe contener pantallas que utilicen al menos una
sentencia SQL que sea enviada a la base de <latos, para que funcione como
hlaiwo dC' los ataqnes de inyección dC' f'ódip;o a ejC'C'lltar.
2. Construcción del proxy.
Sen·ido de ~licrosoft Windows R , creado mediantP Windows Comunnica
tion Fo1111datio11 [32], d cual debe funcionar C'Otno proxy entre la aplicación
y la base de datos. además <le contar con la capacidad de generar llaves
aleatorias peric'>dicamente, para el consumo de las aplicaciones que utilizan
la df'f C'nsa.
AdicionahnentP. el proxy d ebe tener la capaddad de traducir una consulta
aleatorizada al lenguaje natural SQL. µara que pueda ser procesada por
la bnsc <le <latos ~· <lPvolnr d rcsulta<lo espl•ra<lo por la aplintdún, <le for
ma que el uso del prox~· sea transparente para las pantallas dP la aplicación.
El pruxy. <h·lll' cont ctier la cuufiguraeiún <lvl t icmpo en que <lcbc realizar
<>l «amhio <IP la llm·P. dP forma que pueda f'lltrcgarla a rnda aplicación
dientP y a la vez, tenga la c·apad<lad de trad11dr las cousult.fls que span
c11viadas por hts aµlicado111•:-. dieut.t'. Para los dt>t·to:-; <ll• csll' trabajo. se
28
definió que los t.iempos a manejar para el cambio de llave, son de JO, 60 y
90 sPgnn<los, r.stn configuración no sigur un con1portnmím1to o nnn guía
de implementación, sino que fueron elegidos manualmente por considerarse
una Yentana de tiempo considerable entre cada cambio.
3. Instalación de la base de datos.
Como parte de la arquitectura propuesta para el modelo SQLRand, se cuen
ta con un motor de bases de datos, en el cual se debe instalar el repositorio
<le los <latos para el uso <le la aplicació11.
Para el uso <le la aplicadóu, se <lebe contar c:on una estructura bcbka <le
al menos 2 tabla.o; con <latos contf'ni<los, lo cual permite conobonu- que los
ataques ejecutados resultan exitosos cuando así se indique.
4. Creación de la herramienta para ejecución de ataques.
Como partr. dr. la r.jr.cución <lr. los ataques dr in~·rcdón SQL, se errará una
herramienta que cuente con la capacidad de ejecutar las técnicas más cono
cidas para inyección de código, para tratar de realizar ataques de inyección
contra la aplicación vulucrable. Esta herramienta, será <liseüa<la para que
pueda medir la cantidad de ataques que entran a la base de datos, para
poder obtener datos más reales de cada ejecución de ataques.
Eu esta herramieuta, se efectúa la simulac.:ión <le que el atacante logra ob
trnr.r In llave gr.11rrn<la por d proxy y n~aliza seri<'s clr ataquf!s s<'<'H<'l1Cial1•s,
de esta forma se puede medir la cantidad de envíos que lograría al atacantf'
ejecutar en la base de datos, lo cual permite que se pue<la derivar la efec
tiYidncl rkl tirmpo dr cambio. rsto al rr.produdr Ja.., prudm.o; con t.o<los los
tiempos ddínidos para los cambios de llave.
5 . Ejecución de los ataques:
En ca<la prueba, :;e clchcu cjcc·utm- los Ht.aqucs cldiui<los, para que se pue<lan
1u1alizar los datos que se obtienen por parte• ele la herramienta. y verificar
manualmente los resultados <le la misma.
29
Cada ataque se crea mediante la invoc·ación a fa dirección en la que está
instalada la aplicación n1hwrablC', C'm·im1clo inyC'cciones de código en lo."
parámetros que recibe la aplicación. y recolectando los resultados de cada
ejecución en archivos de texto, mismos que podrán ser analizados manual
mente posterior a la cjct'udóu <le los <1taqucs. Cada uuo <le los ataques, iu
cluye pequeños segmentos de SQL eu los datos de entrada de la aplicación,
con el cuidado previo de que la consulta a formar sea correcta sintáctica-
111e11tc, para así tcucr seguridad de que cu caso <le µasar por el proxy, vau a
tener un resultado correcto contra la base de datos.
3.3.2. Variable de respuesta en SQLR.and
Para la recolección dC' l~ resultados, SC' definirá 1111 set dC' ataq11cs qnC' serán
en\'iados por la herramienta atacante hacia la base de datos. De la totalidad de
ataques enviados, se realizará un conteo de los que sean rechazados por el proxy
antC's r!C' que sean C'jC'cntados contra la ha."" dC' datos. El porcentaje de ataquC's
exitosos, será la división de todos los ataques detectados dividido entre la totali
dad de ataques enviados a la base de datos.
Según la elaboracióu de la herramienta de ataques y las posibilidades de
ineyección SQL programadas, un ataque correctamente detectado por el proxy,
será. el que el ser em·ia<lo desde la herramicuta i11Yocau<lo la aµlirncióu , resulte eu
1111 error de sintaxis por la t.rarlncdón del proxy en la cons11lta de la aplicación.
Dado lo anterior, se define <·omo variable de respuesta el Porcentaje de ata
ques detectados por el proxy.
La fórmula de medición para la variable de respuesta es la siguiente:
PF: AT/TA * 100 ( 1 )
Doude:
F' F: Porcentaje de éxito
:m
AT AtaquPs redrn.za<los
T .1 Total a t a<¡H<'S rnvia.<los
3.4. Implementación en Árboles de decisión
Basado en la descripdón <le la arquitectura del modelo, presentada en 2, se
procr.<lió con la implmnr.ntadón de los componrntrs nrc·rsru·ios para la ejecución y
evaluación. seguido de analizar la variable de respuesta que se obtuvo para poder
medir la seguridad desde el punt.o de vista deseado en este trabajo.
3.4.1. Implementación del modelo en Árboles de decisión
En esta sección se describe con mayor detalle Jos pasos necesarios para realizar
la implcment.aciún <le t.o<lo el mo<ldo <le clasificacióu mc<liautc árboles <le <lccisiúu,
~· Ja..;; hPn·amienta..;; mencionada." f'n la sPcción anterior.
Se generaron y utilizaron consultas con y sin inyección SQL. Cada tipo requirió
metodologías distintas para ser grneradas.
En la fi~nrn 22 se muestra la arquitrcturn implementarla para la drtecdón por
árboles de decisión. En el paso 1 se realizan llamadas a la aplicación web, estos
llamados se llevan a cabo desd<' SQLMap para generar las consultas con inyección
Y desdr nua consola clrsarrollada para rl rnvío de consultas sin inyección. En rl
paso 2 la aplicación web toma una consulta al azar desde un directorio de archivos
SQL para ser ejecutado en la base de datos. En el paso 3 se almacena en un archivo
ele texto la con:mlta juuto con los <latos <le entrada <ld usuario, quien cu cst.c caso
es la herramienta que hace la im·ocación. En el paso 4 se efectúa la ejecución de
la consulta seleccionada en Ja hase de datos y se retorna el resultado hacia la
)>HlltHJla.
l. --
sqlmap" ConM>l.oUlll
l
Ll.im<1dd di URL
lnvendndo poramt>tro\_
llamada~ \1n inyecc1on
Ejecucioo del sct1pt en la
B;i,e de D•to>
Eleccoon del q~rv preformado po)ra e¡ecu!.lr
Apllcfclón Vuln •ble
l. r • . r--.
2
SQL Q~r1e\ creado\
mdnu.tlmC"nte Pdra ~' u1il1zado~ por la aph(.ac1ón
Alm.uencJm•ento del quPry ele-g1do Junro a
lo'> PcHitmeuo~ t'nvo•do> por SQlMAP
Co•uult<1• e-1ecutad1n
por la
.>_pllcJc+on
4
Figura 22: Arquit<·ctura para la implen1<·11t;wi1'111 del modelo hru;ado e11 la solución <·on árboles de decisión .
Generación de consultas con inyección SQL
Para t>l Pnvío de consultru; <·011 i11ye<-ciú11 SQL. st> utilizó SQL~lap [39j. la cual
t>stará <:>11viando repeticlamentt> solicitudes a la dirt>edón URL donde se nm11tiene
instalada la aplicaeión. SQJ~lap t>feC'tÚa 1111111t'l'osas llamadas a la dire<"<:iún t>ll la
<¡ne se encuentra Ja apliC'aciún. t>llviando distintos segmentos i11ye<:tados <' ll los
campos del usuario. por lo cual permitP la gt>11Pració11 ele gra11des C'antidadt>s dt>
«onsult~ con divt>rsos segnwntos de código imH·t ados.
Las solidtt1dC's em·iadas por SQL\lap, co11tie11t•11 i11~·ección de parámetro:.; uti
lizando todas las téc11iea.-; me11cionada:-; Pll la secciú11 2. 1.
Generación de consultas sin inyección SQL
En el c·a.-;o del envío de consulta.-; sin i11~·pcci<ín de SQL. se creó una apli<'adón
de n)))sola c¡Ut> realizó los llamados al URL ele la aplicación, de una forma similar
a la que han> SQL~lap. pero sin inyeeción de código en los eampos de enuada del
usua1·io. esto permite que se pueda almacenar en el archivo de consultas. arnhos
32
tipos de clasificación (inyectadas y no inyectadas).
Al poder separar ambos métodos de llamado en la misma aplicación, se brin
da la facilidad <le que, en el momento de almacenar las consultas generadas, se
¡m<lieron almacenar los <latos para clasificar si la c:ousulta coutcuía o uo in~·cn:iúu
de código, esto fue fundamental para el aprendizaje y clasificación por partf> dPl
árbol.
Los aspectos y pasos efectuados para la implementación del modelo se detallan
a continuación:
l. Sclc<.:ciún <le los atributos que se van a utilizar en las consulta8.
2. Instalación dr Base <le Datos.
3. Elaboración <lr consulta." para la aplicación.
4. Construcción <lr una aplicación weh vnlnerahle.
5. Instalación y configuración <lr henmnienta para ataques inyccta<lrn;(SQLmap).
6. EjPCllC'ión <le los ataqnPs inyPcta<los.
7. Instalación y configuración de herramienta para ataques sin inyección.
8. Ejecución de los ataques sin inyección.
9. Creación <le herramienta para generar formato at:eptado por árbol.
10. Instalación de Weka.
11. Generación <le dasificador en Weka.
Cada uno <l<' los pa:;os anteriores. <:omponc la meto<lologfo <le implPmcntadún
~· Pjf>C'll<'ióu clr> t~c11ica c~valna<la. Srgni<lanwntf> Sf> dPt.alla la const.rucdém clf> cada
uno de los pa:-;m; in\·olucrados en el proceso:
1. Selección de los atributos que se van a utilizar en las consultas.
La selección de atributos se hizo de forma empírica y manual, realizando
revisiones <le consultas reC'olectadas, preYiamente, las cuales fueron genera
da." por SQLmap durnnt<' la <'j<>cnción de a.taq11ci;, para <'Sto S<' digrn los
atributos o características que parezcan contener algún patrón o pista pa
ra identificar inyección de código o de igual forma, los que a criterio <lel
cxpcri111cuta<lor .se i<lc11tifiquc11 como los ma:; apropia<los para las pruebas.
La lista de atributos seleccionados posterior a la revisión y estudio manual
<le t'ou.sulta.-; se muestran en la Tabla 1.
Tahla 1: Lista dr atributos y medidas rlrgidos para la da.'iificadón Atributo Descripción ¡ Tipo <le Cousulta Inscrt/Sclcet Comentarios Cauti<la<l Nulls Cantidad Operadores lógicos Paréntesis Tablas Comparadores Comilla.<; simples Puuto ~· comas Uuiom;
2. Instalación de la Base de Datos.
Cantidad Cantidad Cantidad Cantidad Cantidad Cant ida<l
Si/Xo
Se <lcbe instalar uua ba.-;r de datos con una estructura básica de dos tabla.<;.
las cuales permitan la interacción con las pantallas de la aplicación web y
la ejecudóu <le los ataques <l(~ i11yeedó11 SQL.
3. Elaboración de consultas para la aplicación.
Basado en la lista de atributos elegidos, se elaboraron los scripts fueron
utilizados por la aplkadóu tlesarrolhula auteriormeute, estos script.~ <lt·beu
<·mlt.1'111'1' lllH\ mrzda clr toda; los atributos, rlc forma que al cje<·ut ar la.-;
!Wllt<'ndas SQL dt• 111<111ern aka.toria, se obtenga una gnrn variedad de los
ttt ribut os s<>len:ionados y se evit.c seguir un patrón de contenido de estos
atrilmt.os <'11 los s'n.pl.~ qnr 110 conti<'ll<'ll inyrcción <lr código.
34
Los scripts elaborados deben contemplar todas las siguientes combinaciones
de consultas:
• sin ninguno de los atributos.
• con uno <le los atributos.
• con dos o más atributos.
El objetivo de este filtro es garantizar que. tanto los scripts inyectados como
los que no contienen inyección, poseen los mismos atributos (ver Tabla 1),
de esta forma los atributos estarán presentes de una forma homogénea en
los datos que se ingresen al árbol de decisión.
4. Construcción de aplicación web vulnerable.
Como parte de la instaladón, se desarrolló una aplicación que con una ven
tana para captura de parámetros y que permitina además la ejecución de
consultru; SQL, seleccionando la consulta de forma aleatoria desde reposi
torio de 20 archivos distintos, los cuales combinan los diferentes atributos
que se evaluarán para la clasificación por parte del árbol de decisi<'m (Yer
l< 1gura 2:~).
Figura 2a: Ejemplo de pantalla desarrollada para la aplicación vulnerable utilizada.
La aplicación desarrollada utiliza metodologías de concatenado de los paráme
tros a la consulta (ver ejemplo en figura 24), por medio del símbolo · y uo
35
como parámetros adjuntos al script. de modo que permita a la herramienta
de inyección SQL explotar estas vul11erabilidades y obtener informadón de
la base de datos.
consulta • consulta + identificador; c•.C01M1andText • consulta;!
r • c~. E xecuteR~ad~r(),
dt • nt"h' ();
dt.Loed( r ) ;
Figura 24: Ejemplo de concatenación de eade11as. ut i 1 izado por la aplicac:-ión vulnerable para el manejo de las commltas SQL.
Se desanoll<'> además un parc\im·t ro que permit t' configurar la aplkadó11
para guardar las seutt>lll'ia.-:; de SQL que son ejecutadas en la hast' de elatos
en dos archivos distintos dependiendo de si tiene inyección de nídigo o 110.
( \'er ejemplo en fi!!;llnt 2.r>).
/ /PARAME!ROS :miau.u:s r utaGuarDarArcb1vos-C:\SQLinJect1on\ConinJection.tst
Figura 25: :\H'hivo de configuradón elt> la apli1·;t<·i<'>11 ndnerahlP. ele forma q1w permita al11111ct>1mr las consulta.-; en clist i11tos ard1i\·o .... clt• t<•xto.
5. Instalación y configuración de herramienta para ataques iny(~cta-
dos(SQLmap).
O\\"ASP ofrece una distribución fádl tlt> instalar dt> SQLl\laJ> 1. ·''ª qut> 1'111i-
c·amt>nte se rt>quiere de:;cargar los archivos y colocarlos en el c·omputaclor
t•n el que se dPsea utilizar, posteriormente uti !izando línea de comandos o
un ard1i,·o de t>xtendón .bat se debe im·ocar el archivo sqlmap.py y en
viar los parámetros definidos para la prueba a realizar. En la Figura 2G :-it'
rnuestra 1111 f:'jemplo del comando utilizado para la invocación de la herrai
menta SQLmap. enviando los paní.111etros a utilizar por medio de la línea
de comando. 1 SQLl\lap se puede descargar en la página pri11dpal http://sqhnap.org
lJ ·h~~p: loc•lho•t:399101 .-.~,..
-ptSSQL -D Servicio•TQ:.:1:
-BElJSTO t sean t?'&C•S•l•ct.txt • •c•n_r•pc?'t. txt
"'W'l.ndCWI
> ••li.d.11. txt
Figura 26: Ejemplo de líneas de comando utilizadas para f>l llamado a SQLmap
Una vez invocada la aplicacióu SQLmap, esta comenzará la ejecución de los
ataques y pruebas contra la aplicación. solicitando ademas, algunas con
firmaciones durante el proceso, por lo quf> se debe dar seg11imiento a los
ataques para que la herramienta logn' m·anzar correctamente.
6. Ejecución de los ataques inyectados.
Postt>rior a la eonfiguración de los ataquPs que van a ser enviados por SQL
map, se almacenan los datos en un archivo de texto. con extención .bat
lo cual permitirá que los ataques sean eje<·utados fácilmente invocando el
archivo indicado.
Durante la ejecución de cada set de ataqw•s. la aplicación estará recolee
tando y almacenando en un archivo de tt•xto plano todos los scripts que
se reciben por medio de la pantalla de recolección de parámetros, de for
ma que estos datos puedan ser procesados posteriormente para obtener lw
medida.s de los atributos en eada uno de ellos. Cabe resaltar que el proceso
de almacenamiento de los scripts recibidos en la aplicación, se realiza cou
un formato pre\'iamente establecido, lo que permite que el procesamiento
posterior st et más sencillo.
7. Instalación y configuración de herramienta para ataques sin in
yección.
Para la generación de consultas siu iuyeeción de código. se crea una herra
mienta que permita múltiples invocaciones a la aplicación vulnerable, pero
evitando introducir segmentos de código SQL en los datos de entrada del
usuario. esto permite que la aplicación pueda geuerar uua gran cantidad de
:~7
consultas sin inyección, utilizando las consult.as definidas. cst o hact' c¡1w se
cuent <' C'Oll una ma~·or varie<la<l y a la Y<'Z S<' as<'gnrn <'l uso ele' todos loR
atributos definidos para el árbol. Lo anterior pt>rmitc afirmar que en ambos
mundos (inyección y no inyección), se cuente con diversidad de consultas
utilizando todos los atributos establecidos.
8. Ejecución de los ataques sin inyección.
Utilizando la herramienta creada en el paso anterior, se introduce la di
r<'cción WC'h qn<' p<'rmita invocar la ventana <lr la aplicación vulnernhl<',
posteriormente se comenzará a invocar la dirección indicarla y cambiando
los datos de entrada del usuario en los llamados, enviando distintos núnwros
o letras. Estos llmuados se realizan cu ciclos de 1000 ejecuciones. las n•t·cs
que se considere necesario para obtener la mayor cantidad de consultas para
el entrenamiento del árbol.
9. Creación de herramienta para generar formato aceptado por árbol.
Prn;t.erior a lé!. illlpresió11 de las rnwmltas recibidas por la aµlic:adó11, :-;e
crt'a una aplicación <le consola en t'l lenguagt' C#, la cual estar;\ enc-argmla
de leer y procesar los archivos de texto generados por la aplicación, con
las consult.as in.vcc-t.adas y las no inyectadas y a partir de ahí, gent-rnr t'l
archivo con formato <l<' . <:81' que será procC'sa<lo por Weka para <'ll a11álisis.
utilizando árboles de decisión.
El r<'snlt.a<lo <l<' los elatos g<'nera<los, SC' 11111cst.ra en la figura 27, c'stc' formato
es aceptado por la herramit'nta \Veka.
~fat•.
· "' · 2,0.No
· " · 2. º·"° .o, 2, O,tlo , O, 2, O, llo ,0,2,0,No ,0,2, J , 'te•
.0.2,0.'t•• ,IJ,2, l, Ye• ,O, 2, l, Ye• ,0,.,2,Y«• ,0,4,2,Yel
,o,t. f. "••
38
Figura 27: Formato de archivo procesado por \Veka para generar u11 árbol de decisión.
10. Instalación de Weka.
Para instalar \Veka. se debe descargar la última versic'>n en la página de la
Universidad de Waikato [4] y realizar la instalación en la máquina destino.
Es importante mencionar que la he11 ,unienta está desarrollada en el lenguaje
de programación Ja\'a [5], por lo que se debe contar con esta plataforma
actualizada previo a la instalaC'ión de Weka.
11. Generación de clasificador en Weka.
Una vez instalado \Veka. se procedt> a incluir el archivo resultantt> del paso
3.4. l utilizando la interfaz de la aplicación Weka, para esto se deben st>guir
los pasos que se mencionan a continuación:
a) Abrir Weka y Elegir la aplicación E:i:plorador.
b) Elegir la opción A brír archivo ~· busC'<lr de esta forma el archi rn gene
rado para este propósito.
e) Verificar que el archivo sea cargado eorreetamente por \Ve ka y que
todos los atributos sean identifü éldos correctamente.
d) Seleccionar la ventana de Clasificar p«ra elegir las opciones de auálbis
de los datos cargados.
e) En el botón de Clasificador se debe elegir la opción con el algoritmo
más adecuado al estudio que se desee realizar, para el caso de este
trabajo se utiliza árboles/ J48 corre;pondiente a árboles de decisión.
f) Se deben elegir los datos para la opción de Opciones de prufbas, esto
de acuerdo a las prueba<; y los parámetros elegidos previamente. en
39
el caso de este estudio, la configuración se realiza con uu 40 % de los
datos para Pnt.rPnamif'nto y d rPStantc para da..'>ificadón.
g) Seleccionar la opción Comenzar, lo Cllal realizará. el proceso seleccio
nado sf'gún Jos parámf'tro.'> y mo.<;trará los rf'sultados corrf'spondient.Ps.
Posterior a completar el proceso de implementación y clasificación utilizan
do Weka [4], es necesario hacer uu análisis <le los resultados que <le ahí se
dPrivan, a..<;Í como algunos contf'O.'> dP lo.'> promf'dios y aparicionP.<; rlf' cada
tipo de atributo, para tratar de identificar patrones en los datos utilizados
que puedan influir en los resultados que se obtienen del proceso.
3.4.2. Variable de respuesta en Árboles de decisión
La implementación del árbol de decisión debe realizar la clasificación de las
wusulta.s recolectadas, utilizau<lo el 40 o/i. <le los <latos para el entrcuamieuto y
aprendizaje del algoritmo, el 60 3 restante para la clasificación de las consultas
según lo aprendido. El porcentaje de sentencias clasificadas correctamente, se
tomará como el número <le consultas que seau clasificadas por el árbol <le <leósióu
y qu~ f'l r~ultado rnincida con la da...,ifirnción a.'>ignada durantf' la capturad~ la
consulta, dividido entre la totalidad de las consultas procesadas por el árbol de
decisión.
Para mf'dir PI proc.P.so ant.Prior, sP. dcfinP. como variablf' dP rPsptwst.a PI Por
centaje de consultas clasificadas correctamente.
La fórmula utilizada p<u-a la \'ariliblc <le respuesta es la :;iguicute:
X TC/TA * 100
Donde:
X Porcent.a.je <le <·owmlta:-; d<'lsifirn.<las correctamente
TC Total d<' c.011s11ltas da.'>ific.adas c.mT<'c.t.anwnt.<'
TA Total de Ataques
(2)
-10
3.5. Evaluación
Para la evaluación d<> las metodologías. se discut.eu las diversas pruebas y
m1álisis <>fort nado previo a la <ldinidón <le los parámetros que S<' utilizarnu Pll
< ad;l una de las pruebas. La forma de elegir los parámetros y los valores que se
decidió utilizar en cada uno de ellos.
Relacionado al ambiente de desarrollo, ambas pruebas, se ejecutaron en un
único computador, el cual cuenta con un procesador, de 4 núcleos de 1.4 GHZ
de vdocídad, con GGD ele memoria RAM y eu un sistema operativo Wiu<lows 7
Home Prerninm.
3.5.1. Evaluación en SQLrand
En el caso <le SQLRan<l, principalmente se realizaron prnehas ron rli.stintm;
\"al ores para los tiempos de cambio de la llave dinámica. Al utilizar periodos de
tiempo muy cortos, la aplicación o aplicaciones cliente podrían verse afecta<las
rl<>hido a qu<> esta.-. rleh<>n ohten<>r la llave aleatoria y utilizarla <>n sus consultas
previo al envió de los datos hada el proxy. Un periodo de tiempo muy c>xteuso
para el rnmbio de llave, puede permitir que un ata.cante que logre obtener la llave
aleatoria, tenga el sufidcnte tiempo no solo ele inyectar l'UUsulta8, sino también
de obtener datos impo1tantes y sensibles.
El reto en la evaluación de la metodología, es nt.ílizar el intervctlo de tiempo que
mejor se adapte a hi llCl'Csi<lad ele la aµlicadóu y que sea lo 111eú; n .. "'<l ud<lo µosibll'
cl<•srle rl punto de vista de la ventana de ataques.
Posterior a múltiples simula.dones ele atciques cou SQLmap y mc<lidoncs cl<
t.i<'mpo para dct<>rminar lo qn<> s<> tarrla en obtener o avanzar en <>l proceso <1<>
obtención de los datos, se definió que los tiempos a utilizar en la.<1 pruebas. St•rían
de 30,60 y 90 segundos. ~·a que se creyó que esos tiempos permiten un flujo di'
ro11nmkndó11 normal cu aplkadou<>s. y adc>má.<1 :-;on tic•mpos lo snfici<•11tc•mc•ntc•
reducidos (·01110 para que u11 atacante logre pc11ctrar el sistema e ingn•sar a 1<1 lHISl'
de• elatos. en <1rldante el trabajo propuesto, rleherá. determinar C"ttál es ni lll<'jor
-11
tiempo, con respecto a los resultados obtenidos.
En el proc<'so O<' ataqu<'s, s<' analizaron la cant.i<lacl <le V<'<'<'S qu<' un ataqu<' sis
tematizado podía invocar una dirección web, y basado en esto se estableció que
se debía trabajar con conjuntos de ataques de 50 intentos de inyección por ca
da ronda, y al combinar las variabk-s en juego, como lo son tipo de consulta y
tiempos de cambio en la llave aleatoria, se llegó a la conclusión de que 8<' debía
realizar cada. conjunto de ataques al menos 90 veces, para lograr combinar las
nu"iablcs con los tiempos de cambio. No se realizaron medicionc~ e:,;pccializadas
para poder determinar si estadísticamente la cantidad de intentos por ataque,
po<lía influir en los resultados, sino que las pruebas realizadas previamente, solo
s<· limitaron a verificar que el los 50 intento:,;, :,;e podrían cubrir en periodos de
ha ... t.a 90 s<'gun<los, S<'gÚn d tiempo d<' respuesta <le la aplicación weh.
3.5.2. Evaluación en detección por árboles de decisión
El trabajo previo para la.., pruehas con árboles, debió ser 1111 poco má." ex
tenso, ya que se necesitó recolectar gran cantidad de consultas SQL previamente
ejecutadas mediante SQLmap [39] donde se hubiera podido comprobar que se
dicrn inyc'Cción de código obtenido datos de:,;de la base de datos. Una vez que :,;e
tenían suficientes consultas almacenadas, se procedió a analizarlas manualmente
y posteriormente, determinar el conjunto de atributos que mejor funcionara para
el árbol, y que lograría identificar y dasifü:ar correctamente la inyección de código.
Los criterios utilizados para la definición de los atributos, no fueron definidos
previamente, sino que se derivaron empíricamente durante la revisión manual de
la." C'onsult.as almac<'nacla.-., toman<lo en cuenta a.-.p<'ctos como:
l. Cantidad <le repet.idon<'s en la. consulta
2. Diferencia. a simple vista con respecto a una consulta normal
:~ Aspectos no utilizados ele normalmente en consultas, como el término null.
42
3.6. Comparación de las 1netodologías
Desde un punto de vista del proceso como se obtienen los datos, ambas técnicas
no son iguales, y por ende no son comparahlcs en igualdad de condiciones, sin
embargo, se consideró que el objetivo final de ambas técnicas es proporcionar
seguridad a una aplicación, contra. ataques de inyección de SQL. Por la. razón
ant<'rior se dPfinió qur. indistintamr.utr. dr. la forma r.n qur. se r<'alir<' la medición
del porcentaje de éxito en cada metodología, finalmente se pueden comparar desde
el punto de vista de la seguridad que estas brindan.
Para poder comparar ambas técnicas cu un contexto similar, se definieron como
variables de respuesta el porcentaje de éxito en la detección o clasificación de
ataques con inyección SQL, de forma que al final del proceso, ,. basado en la
fórmula que cada una <le las técnicas utíliza para llegar a est.e resultado, finalmente
se mntó con dos varia.bles de medición que se podían compa.rn.r y determinar
diferencias entre ellas.
" 4. RESULTADOS Y ANALISIS
Con respecto a la cobertura en aspectos de scg;nridarl, se rrafo:aron n1<'rlicionrs
al porcentaje de aciertos qne se obtuvieron con C"ada una de las técnicas evaluada..,;
en este trabajo. Con relación a la técnica de SQLrand [11] se mide el porcentajl'
dr intrntos de inyección que efoct.ivamcnt.e logran el objetivo clr akammr la hru;;r
de datos y no pueden ser bloqueados por la defensa.
En el caso de los árboles de decisión [18] se mide la cantidad de consultas qtte
son correctamente dW>ifica<la.8 por el árbol <le <lcdsióu, cst.o en otras palabra.-; c.-;
el porcentaje de efectividad que tendrá la herramienta para identificar consultas
o segmentos de código que contienen inyección SQL.
4.1. Resultados en SQLRand
Posterior a la ejecución de los ataques planteados, se obtiene en promedio uu
24,3 % <le éxito en los ataques que lograron llegar y ser ejecutados contra la b~c
<lec datos de forma correr.ta. Según se Ulllf'stra en la tahla 2, Sf' enviaron rn total
90 ataques, formados ca<la uno por 50 intentos de inyección contra la base de
datos.
Dado lo anterior, se obtiene que el porcentaje de efectividad de la herrnmi<•nta
al bloquear los ataques de inyección SQL recibidos, es de un 75. 7 3.
Tabla 2: Promedio de ataques bloqueados efectivamente con la técnica <le SQLrancl.
Rubro Cantidad de ataques l11knt08 <le iuyc<'dón por cada atnquc Inyecciones logradas Ataques efectivamente bloqueados Desviación estándar
Valor t
El tiempo de inicio y finalización de cada uno de los ataques. fup sin<'ronizaclo
contra el tiPmpo en que la defensa realiza rl rnmbio ele llave de aleatoriz1wi611. il<'
fonua c1ue fue sirnula<lo <le uua mejor forma el ambieut t! rl'al <lt> Hl<Htlll'.
De acuerdo al análisis descriptivo, mostrado en la tabla 3, se puede notar que
ha:-.' ha.c;tante diforcnda rntrc el valor mínimo y el valor máximo, mostrando una
Yariación significativa del promedio obtenido en el ejercido.
Tabla 3: Resultados descriptivos cu las prueba . ., <le SQLRau<l.
Al separar los resultados y distribuirlos entre los valores en segundos elegidos
para el tiempo en que se realiza el cambio de la llave que aleatoriza las consultas
SQL. se puede notar, según la tabla 3 que el promedio <le aciertos <le la hcrramicu
ta al evadir los ataques de inyección, tiene una tendencia a disminuir conforme
se aumenta el tiempo en que se mantiene la misma llave de diversificación. Este
resultado es esperado, ya que al aumentar la cauti<la<l <le segundos para el t:ambio
de llave, el atacante podrá hacer una mayor cantidad de intentos contra la base
de datos antes de que la ventana de tiempo se cierre y deba reiniciar el proceso
para obtener la frase <le aleatorización uueYt1.meute.
Tabla -t: Resultados descriptivos en las pruebas de SQLRand distribuido por la rnntidad de tiempo para el cambio de la llave.
% TiempOde -llave Promedio Desviación estándar Mínimo Máximo
30 0,840 0,101 0,60 0,960 60 0,811 0,119 0,580 0,960 90 0,621 0,160 0,40 0,940
Dt• igual fonua, eu la figura 28 se muestra la frec:uen"iH ol>t eui<la Pll la:-> pnu~lm:-;
rPalizada.c; a SQLRand, lo cual muestra una ligPra tPndcnda en los rf'snltmlos por
t'JJC'Üua del 80 3 de detecciones correctas, sin embargo también se obtuvierou
algunos resultados inferiores al 50% <le detecciones correctas. t>sto puede afedar
<'l r<'mlimi<'nt.o o funcionalidad <'11 <'l esf·<'nario de una aplkndón real. Cahe resaltar
que. se muestra un espacio vacío entre 0.5 y 0.6 :'-'ª que <'JI los r<'snlta<los no se
pn~c·utaron porcentajes entrP el 50 :'-' 60%.
º' 06 07 º' 0.9 1.0 l1 Porctnt,¡J• deo .aUque5 bloqUNdos cOfr.ct.anwntt
Miedw O 1S JJ
O..• ... o lit:
~ 1gura 28: Histograma de freeuenc·ias en los resultados de SQLRand.
4.2. Resultados en Árboles de decisión
¡ .-.
Utilizando el algoritmo J48 í 1) de Weka j-1 ¡. st> i11gresaron los datos rernlecta
dos de las pruebas y formateados para qut> sean ac·t>ptados por \Vt>ka.
De acuerdo al árbol generado por \V1·ka. se logra en promedio una clasifica
ción correcta del 99. 73 % de los registros. lo cual muestra una alta t>ft>cti viciad del
modelo para la dasificación de co11sultas .\· dete("dóu de i11yecció11 SQL.
E11 la tabla 5, se muestra el porcentaje dt> datos clasificados correctamente
por el modelo de \Veka. El porcentaje de aciertos es alto en todos los ca.o.;os. con
diferencias muy reducida.<;, lo que muestra que el co11texto de las consultas n•ali
zadas por la aplicaeión. además de los atributos st>leccionados para este trnbajo
y el conjunto de datos n•colectados. son fácilme11te manejados por el árbol de
decisión en la clru;ificación de los estatutos SQL proporeionados.
Tabla 5: Porn'ntajc de rxitos ('n árhoki-. <le df'('isióu: <l<' ¡\('U<'r<lo a la porción el<' los datos utilizada ¡ntra e11trc11a111icut.o.
3 Entrenamiento % E;<lto ~
10 99,7295 20 99,6145 30 99,6058 40 99,7633 50 99,7890 60 99,7160 70 99,7971 80 !J!J,8174 90 99,7971
En la tabla 6 se muestra el análisis descriptivo derivado de Jos resultados
obtenidos. En general se puede notar una desviación estándar relativamente ba
ja, excepto para algunos de los atributos elegidos, como lo son la. cantidad <le
paréntesis contenido.-. en carla consulta, en la que la <lifcrcnda del promc<lio de
las consultas que tienen y las que no tienen inyección de código es bastante alto
(39,55 y 3,21) respectivamente.
De la misma forma, se puede notar en el atributo Cantidad de tablas para el
cual los resultados son (2, 73 y 20,0).
Se muestra igualmente una tendencia a aumento en los promedios de la ma
yoría de los atributos cuando existe inyección de código en las consultas, lo cual
puede ayudar al proceso de dru;ificadón en d ;:Íl'Lol de <lcdsióu al igual que el
porcentaje de aciertos derivarlo del proceso.
-17
Tabla 6: nr.sult ados descriptivos agrupados por carla variabl<' rlrl árhol <lr rl<'dsión creado µara la dasifü:adón de los datos.
Inyección Variable Promedio Dcsv. cstdr Mínimo Máximo
Si Nulls 0,16 0,37 0,00 1,00 Si Operadores 4.79 0.99 1,00 6,00 Si Paren tesis 39,55 12,26 0,00 107,00 Si Tahla." 20,00 6.23 1,00 23,00 Si e omµara<lores 5,95 1,28 1,00 8,00 Si ComillasSimples 3,37 1,56 0,00 8,00 Si Punto Y Coma 0.32 0,47 0,00 2,00 Si Unions 0,06 0,23 0,00 1,00 No Nulls 0,29 0,63 0,00 3,00 No Operadores 2.11 0,63 1,00 3,00 No Paren tesis :t21 2,74 0,00 14,00 No Tabla." 2,73 3,03 1,00 21,00 No Comparadores 3,12 4,08 1,00 28,00 No ComillasSimples 3,22 1,59 0,00 4,00 No PuntoYComa 0,30 0,46 0,00 LOO No Unions 0,17 0,93 0,00 6,00
En la Tabla 7 se muestra la matriz de confusión geuern<la µara el modelo en
uno <le los ca."o." evaluados. En la matriz rle confusión, se obtienen 35 registros en
los que no se puede detectar la inyección de SQL, lo cual representa un 0.3 3 del
total de registros utilizados para clasificación.
Tabla 7: Matriz de confusión obtenida por el proceso de clasificación en \Veka.
Tipo de Clasificación 1 Cl "fi d e . . , s· . . , as1 ca o como
011 mycec1011 m myccc1011 _
5787 32 Con inyección
11 O 89~-- Sin inyección
En la imagen 2!.I se muestra el orden en el que son colm:a<los los atributos
seleccionados para el modelo <le dasificadú11.
r•dore" <• 3 Untoha <•
Parenteau <• 6 Coa1llH5J.mple• <• 4
Comentario• • ye• Parentesis <• S
Querytype • SELECT: no UU3.0/2J.0> Q\>e<flype • INSUT: f"I Cll.01
Pareote.u.t > 5; no 41414.0/8.0> CQ9P6racsor-e• > l
Operedottlll <• l: no (60l.!l/l.OI 1 ap.u4ore1 > 1: y1u (14.0J C'OlllllH!h,mpl~I '.> ': yea t42.01
PArented• > ': ye• (!9.0~
tlnicn• > O: ye• tSSS.Q)
:peradore• > l: ve• º'''·º> !IUllbel' et LeaYU 10
sue et tbc tree 19
-18
Figura 29: Estructura del árbol generado para todos los atributos seleccionados
El orden en el que se generan los atributos. es el orden de relevancia en el
que afectan el resultado final. En la imagen 30 :-;e mw'stra la estructura del árbol
de decisión oht en ido dPI procesamiento de los datos utilizando los 10 atributo~
J. 1gura :30: Estructura del árbol generado para todos los atributos seleccionados.
49
4.2.1. Análisis detallado de atributos
Posterior a los resultados obtenidos por el modelo. se procede a verificar y
se muestra que de la lista de los atril.mtos selecciona<los, algunos de ellos no son
indnidos en d árbol gcnrrado, lo e-na! sr mtwstrn rn la tabla 8.
Tabla 8: Lista <le atributos y me<lidas elegidos para la dasificación
Atributo Utilizado
Tipo de Consulta Si Comentarios Si Nulls Si Operadores lógicos Si Paréntesis Si Tahlfl.<i :'\ () Compara<lo1u; Si Comillas simples Si Punto y comas No Unions Si
Posteriormente, se hizo uu auálisi:s de los atributos que son <le tipo immt"~rico
~· los que son de tipo categóricos con el objetivo de poder determinar si existe
algún patrón de comportamiento que sea el posible generador de los resultados
que brin<la el árbol. Se mmlizan <latos como el promedio <le con:mlta.-; con los
distintos Yalorrs de cada at.rihuto, <l<' forma que sr pneda notar si hay alguna
diferencia muy marcada en los promedios o distribnci!Sn de comentarios por cada
atributo.
4.2.2. Atributos numéricos
Con respecto a los atributos numéricos, la fi~ra 31 muestra un promedio del
Yalor obteui<lo para ca<la uno <le los atributo:-; <le tipo nuwérico. Se pue<lc uot ar
que en el caso de las consultas que contienen inyección. existe una diferencia
bastante grande en la cantidad de paréntesis ~' tr1hL.-1s que se ntilizm1 en ea<la
!'OllSUita. akanzan<lu \'alures <ll' ha:sta el() pan'·11t 1·:-.i:-. por l'OWmlta, esto podría
haf'er qne Pl árbol logrP detPnninar con 11u\.-; fa1ilidad cnanclo un rnmamlo SQL
C'Ontiene inyección.
45 ,0
~ 40,0
.e 35,0 :. 30,0 e
·;;; 25,0 ~ 20,0 :J ~ 15,0
3 10,0
~ 5,0
~ o.o ... e
"' u
• 1 1
Tipo de atributo
• Con inyección
~Sin Inyección
Figura 31: Promedios por cada atrihuto de tipo numérico.
50
En la mayoría de lm; demás atributos, 110 se muestra una diferencia muy
mareada en cuanto a los que contienen inyeccíón y los que no la contie11P11. ade111<1s
como se muestra en la figura 30, el orden en el árbol de decisión de los atributos.
no está directamente relacionado con los que contienen más diferencia en :;w;
promedios.
Es importante notar que, en el ca:;o del atributo Cantidad de tablas aunquP
hay una diferencia notable, entre el promedio de uso para las consulta-; inyectadas
y no inyectadas, este es un atributo que no fue induido en el modelo del árbol, por
lo que 110 se puede asegurar que la cantidad de tablas utilizadas en las sentencias
SQL, sea un determinante para la decisión si :;e contiene irin·<·<·ión de código.
4.2.3. Atributos no numéricos
En cuanto a los atributos que 110 son de tipo numérico, se analizó la cantidad
de apariciones en cada consulta, para verificar si se pre:;euta algún patróu o
comportamiento que permita derivar una relación entre los atributos y el resultado
obtenido. Los conteos de cada atributo no numérico, se muestran en las figuras
32 y 33.
51
10000
t; .. "'&
8000
15 ... 6000 .g
l 4000
;:J 2000 li
• con inyección
Sin lnyecc 1ón
u
o SE LEL T INStRT
Tipo de comando de Id consulld
Figura :J2: Distribud('>11 d<-' las S<-'lll<'lll'ias de acuerdo al tipo <lt> c·o11-.11]1;1
10000 .. 411 ~ 8000 :::1 .. ~ 6000 .g
• Con 1nyeccion
1 4000
! ] 2000 Sin ln y ecc ion
o St No
Indicador de contenido de come11ldrios
Figura :J3: Clasificadó11 de C'onsultas de acuerdo al contenido de c·omentarios.
Existe una mayor cantidad en el conteo d t> ambos atributos cuando la SPllft>ncia
no contiene inyección de l·c)digo, esto aunque es mayormentP dt>hido a que en el
C"onjunto de datos existe una mayor eantidad de eom;ultas sin ill,Yt'l'<0 ión, no es
dt>lt>rminante para predecir t>l comportamiento del árbol de decisión. por lo cual.
si St' obst>n·a la figura 30. se puede notar qut> estos atributos no fu e ron localizados
en las primeras posidones del árbol de decisión.
52
4.3. Comparación de Resultados
En esta seceió11, se elabora una comparación cuantitativa, de forma que permi
ta mostrar la diferencia obtenida de la evaluación a las metodologías, relacionado
directamente con las variables de respuesta elegidas en la sección de metodología.
Por otra parte, se evalúa las condiciones de implementación de cada técnica pre-
sentada, los requbitos y conocimientos previos necesarios para su uso.
4.3.1. Comparación cuantitativa
A pesar de que el contexto de prueba es diferente en cada una de las pruebas
realizadas, el promedio de detección de i11yeceión SQL, es más alto para la técnica
basada en árboles de decisión. En la imagen 34 se muestra la diferencia entre
ambas técnicas, con base en el promedio del resultado de ambas mediciones.
1,20
.:: e: 1.00 _g ti a ".,, -8 ¡¡ 0.80 JI tj
~ ~ " .li 0.60
" " " ... " ~ ij ~ 0,40 g i ... -" .. E 0.20 ~
o.oo SQLRand Árbo~s D"ccsión
T...,nicu d" ci.sificación
Figura 34: Clasificación de consultas de acuerdo al contenido de comentarios.
Además se puede notar, de acuerdo a la imagen 35, que los resultados en el
caso de SQLRand, son más variables al modificar los diferentes atributos de la
prueba, contrario a los resultados en árboles de decisión que a pesar de modificar
los porcentajes de datos utilizados para entrenamiento el resultado tiende a ser
no muy variable y acercarse al 100 % de clasificación correcta.
SQLRand Árboles_Oedsión
<a 1.0 • V ·2 -~ .... .... &. 0.9 111 o -a !! • -¡ ....
0.8
"' • ..2 cu -a
0.1 e: '() •¡;¡ :J ~ ·s 111 0.6 o
SQLRand ÁrbolesJ)edsión
Técnica de defensa
Figura;~;): Üi:;¡wr:;ii'111 de los dato8 en lrn; n•stdtado:; de ambas lt•t·11icas ('\·alt1mlas.
Se puede decir que en SQLRand, se tiene u11 factor más influyente colllo lo es
el periodo de tielllpo en que la defensa mantendr~i la misma llave ele aleatoriza
dó11, Jo cual puede ocasionar que se ge11ere11 algunas diferencias entre !os di:;tintos
re8ttltados y utilizando !o:; mismos atributos.
Un comportamiento similar se refleja en la tabla 9, do11de se muestra que
existe variabilidad lllucho lllayor en los datos de SQLraud que en el caso de los
árboles de decisión. Para el caso de SQLrand. la desviació11 estándar con respecto
a la media puede oscilar al rededor de un lO % lo que hace que el porcentaje de
éxito de la técnica 8ea un poco menos estable en comparación con el árbol de
decisión, para el cual. la desviación está11dar no llega ni al 1 % con respecto al
promedio. Estos resultados, son reflejados de igual manera en la imagen 35. en
el cual se not.a una 1w1.\'or dispersión de los datos alrededor de Ja media, para el
caso de SQLrand.
Tabla !J: Variahili<lad <le lrn; <lato." en nula mrn <l<' las tfrnirns c•Yalna<la.".
Técnica
SQLRand Árboles de decisión Diferencia
Media
0,7573 0,9974
-0,24
4.3.2. Comparación cualitativa
Desviación estándar ~ 0,109
0,0008 0,1088
5-!
SQLRand, es una técnica simple y relativamente fácil de utilizar, la arquitec
tura prescnta<la no contiene una complcji<la<l ::;iguiticativamcnte alta en el proceso
de implementación, el contexto y experiencia en el lenguaje SQL no debe ser ex
tremadamente alto para lograr el uso de SQLRand. El mayor reto con relación
a la implemeut ación de SQLRan<l, es lograr establecer un tiempo prudente para
el cambio <le la llave aleatoria, sin afectar la." aplicaciones inscritas como clientes
del proxy.
Para hacer uso <le una <lcf<'nsa basarla en ñrboles <le decisión, sc <lebe contm
con un mayor conocimiento del lenguaje SQL. esto debido a que es muy necesario
la ejecución de un trabajo previo significativo, como lo es la definición de los
criterios <le datiificación que utilizará el árbol, los cuales preferiblemente <leuen
ser obtenidos y evaluados para asegurar que el comportamiento del árbol es el
desea.do. Se debe tener además la noción de lo que contiene una consulta SQL
con iuyeccióu, ya que es muy importante el proceso <le evaluación <le los <latos
que serán suministrados para el entrenamiento del árbol. Es posible que cada
aplicación y la estructura de datos con la que interactüa demanden un conjunto
<le atributos <listiutos o al menos no to<los compatibles. lo cual hace que el proceso
rl<' <lefinirión y uso sea má." complejo.
5. TIEMPOS DE RESPUESTA
Antes <le utilizar nuevas funcionaliclacles t>ll aplicadoncs empresariules, st> debe
cYaluar el impacto eu reu<limieuto qne <':-;ta::; repn•M•ut an. principalmente 1·uanc.lo
existen usuarios fina.les que intcrnuctúan l:OH estas aplicaciones y estos tiempos se
t.ra<l11ce11 en tiempos <le PspPrn por parte' <lcl usuario. Como parte <lP C'StC' trnhajo,
se evalúa el tiempo que significrt la inclusión <le las def Pnsas presentadas en una
aplicación de uso común, los resultados de esta evaluación. se presentan divididos
por ca<la una <le las técnicas <le <lcfcnsa.
5.1. Tiempos de respuesta en SQLRand
Durante la ejecución de solicitudes al proxy para la traducción y la aleatori
zación de las consultas, se realizaron mediciones a. los tiempos transcurridos para
ca<la una <le las opcracioues, según la tabla 10 se muestra el prome<lio <le tiempo
en mili segundos que se tarda para realizar cada una de las operaciones meucio
nadas anteriormente. Estos tiempos son obtenidos de 1,000 ejecucionPs de cada
una <le las funciouali<la<les, utilizawlo las mismas consultas que se lTCctl"UH parn
las pantallas de la aplicación construida para estas pruPbas.
Tabla 10: Promedio de tiempo para las operaciones de SQL Rand
peración
eatorización aducción
Promedio milisegundos
0.0373 0.1902
5.2. Tiempos de respuesta en árboles de decisión
E11 relación con el proceso de clasificación mediante árboles de decisión, como
se mencionó en l<lS secciones anteriores. se debe agn1par en dos partes:
• Proccsami<'nto dP la 1·m1snlt a para oht.1•11Pl' los at.rihnt.os.
• Clasificación dC' la consnlta por nwclio dP los atributos obtenidos.
Para medir el primer paso (kl pro<:eso. :-;1· tomó una muestra de 30 ejec11ci0111•s
del algorit1110 nea<lo para la-. prudias. mu t'l propósito <le obte11er los <latos 1k
la rn.ntidad dr mili SPgundos q11 sm1 11pc·1•sarios para ('Otnplrtar Pl arnilisis dr la
consulta. en la Figura 36 se 1mwstra el n•snltado del tiempo promedio ohteni<lo
56
al dividir el tiempo total del algoritmo entre el total de consultas analizadas, en
este c·as1> "º'1 2·1.fi l."1 reprr·..;1•11tadas en líneas del archivo dr· 1'1ltrnda.
2.00
1 : 1,50
J 1.00 ~
l I! o.so ~
0,00
Tiempo de ejecución
por consulta en ms
. ~......._ ....... ..
l 2 3 4 s 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
Número de cj~ción
-T~mpo
por consulta
Figura 36: Promedio de mili segu11du,.; por l'unsulta en 1<1 (':\tracción de los atributos.
Adicionalmente. la segunda etapa del algorit1110 es la creación del árbol de
decisión y clasifi<"ación de consultas, basado en los atributos definidos para es
te estudio. En este caso, el proceso se lleva a cabo utilizando Weka [4]. ya que
pos sus algoritmos previamente creados y probados se adapta perfectamente pa
ra este estudio. además reduce la posibilidad de uu impacto signifieativo en el
rendimiento de una aplicacióu si se utilizan estas herramientas para el estudio de
las eonsultas. Los tiempos reportados por Weka en la salida de los resultados del
proceso son:
• Tiempo de eonstruccióu del modelo de árbol: 1, 17 segundos.
• Tiempo de análisis y pruebas O, 17 segundos.
El reporte de los tie111pos de C"onsumo reportados por \Veka. es la medida del
tiempo que en su totalidad se utiliza para la aplicación del algoritmo a la totalidad
de 24,645 línea." en el archivo fuente. lo cual quiere decir que si se efectúa la
operación correspondiente el gasto de tiempo nece:;ario para l registro de consulta
sería muy po<"o significativo en términos de re11dimiento de una aplicación eu
general.
6. CONCLUSIONES
Se presentarou <los metodologías t.otalm<·nt<' <list.iuta.<; y hmmdas <'n t.Pí·11ka.'i
muy diferentes, pero con el mismo propósito, el rual es evitar que las aplicaciones
sean víctimas de un ataque de inyección de código SQL.
Como parte de la evaluación realizada, se implementaron ambas técnicas. pa
ra poder medir de una forma cercana a la forma realizada por los autores de las
t.huicas. Posterior a la implcmcutació11, se cjccntaruu <lifcreutcs pruebas y mc<li
cioues para deterrninai· el porcentaje de éxito que se puede lograr ron cada una de
las técnicas. De igual forma, se llevaron a cabo mediciones del impacto en tiempo
que representan ca<la una <le ellas al ser iutegrn<las en a.plica.dones comunes.
Con respecto al impacto en seguridad, ltis térniras evaluadas agregan un be
neficio considerable, ya que las tasas de clasificación y detección correcta de con
sulta." mal int<>ndona.<la." .'illpcran <'l 70 %, en el ca.'io <lC' SQLRan<l y mayorC's al
90 % para los árboles de decisión.
En términos <le rcn<limicut.o, arnbas iluplcmcutHcioucs rcprcscutau una <lifo
rencia mínima en cuanto a tiempos dt> respuesta utilizados para t>l análisis y
procesamiento de cada una de las consultas. lo c:ual significa que en un ambiente
cu1presarial, <lon<l1! se utiliza.u sctTidorcs dc<lieados para Ja inst.alal'i{m y aloja
mit>nt.o <le la." aplicadones, se podrían t>Spt>rar mín tiempos dt> respuesta menort>s.
lo cual indica que en cuanto al impacto al r<'ndimiento, las soluciones evaluadas
en este trabajo son amigables con las aplic:acioues " pueden ser utiliza<ltts sin
alt.Prar la internccióu y ln l'Xpcri<'nc-Ía d<'I usuario.
58
7. TRABAJO FUTURO
Como t.rnhajo futuro, S<' propone la dahorn.cióu de una co11fi~uració11 de ata
ques más detallada ~' reaL basado en cálculos por tiempo <le la duración de ataques
en ambientes reales, o generando un promedio previo a estudios y generaciones <le
prneha." en amhi<'nt<'R <'mpr<'siuiales, lo cual pucd<' mostrar d<' una forma más pr<'
dsa el tiempo utilizado por la herramienta de ataques para generar la inyección,
y analizar los resultados <le cada una de las respuestas.
Es importante mencionar 4uc los rcsult a<los obtenidos están cou<lidoua<los
al contexto de las consultas generadas pnra este trabajo, y en la aplicación web
creada en la metodología, por lo cual como parte del trabajo futuro, se plantea
utilizar un ambiente más a.dentado. en el que se pueda utilizar una superficie
mucho má.'i amplia del l<'nguaj<' SQL donde se• puedan creru· alt~ volúmenes
de consultas válidas y realizar el estndio en un rango más amplio de consultas y
generando un modelos predictiYos basados en un entrenamiento más preciso y con
una cantidad de dato:;; qne puedan p;meralizarlo para cualquier aplicación, de ei;a
forma es posible obtener conclusiones que permitan la creación de herramientas
genéricas como parte de cualquier aplicación, agregando seguridad a los sistemas
a un bajo costo.
8. ANEXOS
8.1. Tiempos de proceso para generar entrada del árbol
de decisión
En la tabla 11 se muestra la lista de los tiempos dr proceso obtrnidos du
rante las pruebas de generación de archivos que serán procesados por el árbol de
<l cci:~;ión .
Tabla 11: Tiempos para el proC'eso de obtener los atributos de cada consulta SQL. para generar la entrada de \Veka.
Número de ejecución Duración en milisegundos
35.108,00 2 27.945,00 3 34.554,00 4 34.595,00 5 37.616,00 6 38.564,00 1 40.275,00 8 38.074,00 g 38.233,00 10 38.749,00 11 37.932,00 12 37.566,00 13 38.164,00 14 37.704,00 15 45.483,00 16 38.577,00 17 38.984,00 18 :.39.520,00 1 !J 39.913,00 20 39.947,00 21 38.567,00 22 40. 731 ,00 2:3 38.474,00 24 38.379,00 2."1 38.433,00 :w :38.805,00 '27 38.730,00 28 38.222,00 29 38.652,00 JO 38.069,00
(jü
Referencias
[1] .148 algorithm by W<'ka, htt.ps://algorit.hmia.com/algorithms/wcka/.i48.
[2] Owasp, https://www.owasp.org/index.php.
[3] Python, https://www.python.org/.
[4] \Veka 3: Data mining
http://www.cs.waikato.He.uz/ml/wcka/.
[5] Java, htt.ps://ww\\'.jaYa.com/. ~ov 2016.
software
[6] How to protect from sql injection in
in
asp.net
https: / /msdn.mícrosoft .com/en-us/library /ff648339.aspx, 2017.
java,
2017,
[7] Owasp,top. top 10-2013. the ten most critica} web applíca.tion security
risk:;,2013. , 2017.
[8] Shaukat Ali , Azhar Rauf, and Huma Javed. Sqlipa: An authentkat.ion me
chanism against sql injection. 12 2009.
[9] Srinivas AYireddy, Varalakshmí Perumal, Narayan Gowraj, Ram Srivat
sa Kannan , Prashanth Thíuakaran, Suu<larnva<lamun Ganapthi, Ja.-:;hwnnt.
Raj Gunasekarun, and Sruthí Prabhu. Random4: An applícation spedfic
raudomízed encryption algorithm to prevent sql injection, 06 2012.
[10] Pritln'i Bisht., P . l\ladhusudan, and V. :\. Venkatakrishnan. Candid: Dyuamíc
can<lidat<' <'Vahrnt.ions for aut.omat.íc prcv<'ntion of sql inj{'('tion attacks. ACM
Tmns. lnf. Syst. Secur., 13(2):14:1-1-1:39. :\Iarch 2010.
[11] StephenW. Boyd and AngelosD. Keromytís. Sqlrand: Preventíng sql injec
tion a.ttaC'ks. In l\farkus .htkobsson, l\Ioti Yung, and Jianying Zhou, e<litors.
Applir.d Crypto_qrn.phy and Nctwork Sr.r.urif!J, volumc 308!) of Lrrtnrc Nofr8
i11 Computcr Scicncc. pagcs 292--302. Springer Berlin Heidelberg, 200-1.
[12] Angdo Ciampa, Corrndo Aaron Visaggio, and l\Iassimiliano Di Pmta. A
hcurbt il"-lrn:-;e<l approal'h for <h•tec.:t ing sql-iujcct ion vulnera.bilit.ies iu web
(j 1
a.pplic:at.io11s. In Prnceedin_qs of the 2010 ICSE W01-J.:.~hop on Software En
ginr.cring .for Scwrc Sy.'lfcms, SF,SS '10. pap;C's -13--19, NC'w York, NY, USA,
2010. AC'~I.
[13] William R. Cook and Siddhartha Rai. Safe quer~· objects: Statically typed
objects <IS remotely executable queries. In Proceedings of the 27th lntema
tionn.l Co11frrrnrr on Softwn:rr Enginrr.ring, ICSE '05, pagcs 97-106, Ncw
York, NY, USA . 2005. AC~f.
[14] R. Halder and A. Cortesi. Obfuscation-based analysis of sql injection attacks.
In The IEEE symposittm on Comptders ar1d Communications, pages 931-
938. Juuc 2010.
[lG] W. lfalfond, A. Orso, and P. Manolios. Wasp: Protcct.iup; WC'h applicat.ions
using positive tainting and s~Titax-aware evaluation. IEEE Transactions on
Software Engineering. 34(1) :G5-8L Jan 2008.
[16] WG Halfond, Jeremy Viegas, and Alessandro Orso. A classification of sql
injc'Ctiou at.tacks an<l countcn11c<l.8urcs. In P1·uc:ccdútgs uf thc IEEE Jntc:nw
tional Symposium 011 Secure Software Engineering, volume 1, pages 13-15.
IEEE, 2006.
[17] William G. J. Halfond and Alessan<lro Orso. Preventing sql injection at
lat.:ks usiug muncsia. I11 Prucculing.o; uf l./u i!8tlt /nkrn atiunal Conf cn:uc:c 011
Software E11!]inceri11g. IC'SE ·06. pages 79."i-798. ~ew York, NY, USA, 2006.
ACM.
[18] B. Hrunmmthu. B. R. Ram, and P. :Xiranjan. Sql injection attack preven
tiou b&ed 011 dc<..:isio11 tn•1• d&siticatiou. lu 2015 IEEE 9th b1ternctfi01111/
Conference on lntelligent Systems and Control (!SCO), pages 1-5, Jan 2015.
[19] Yao-Wen Hua11g. Fang Yn. C'hristia11 Haug, C'hung-Hunp; Tsai. Der-Tsai Let>.
and Sy-Ycn Kuo. Securing web application <·ode b~· statk analysis and nmti
mc prokl't iou. Iu PnJ<'<'t'lli11g.~ of llw J.1/11 hil1·m11/w11al Co1tfffenn· 011 IVorltl
ll'idF lVl'l1. \ny"· ·0-1. pa~<-s 40- ,i2. :\1·w York, NY, CSA , 2004. AC\1.
62
/20} R. Johari and P. Sha.rrua. A survey on web application vulnerabililies (sqlia,
xss) cxploit.at.ion and serurit.y Pnp;inc for sql inject.ion. In 2012 Int.r.rnaf.ional
Conference on Communication System.8 and Network Technologies, pages
453-458, !\lay 2012.
[21] A. Joshi aud V. Geetha. Sql injectiou detection using machine learning. In
2014 lnteni.ational Conjerence on Control, Instrumentation, Communication
and Computational Tcchnologies (ICCICCT), pagci:; 1111-1115, July 2014.
[22] V. Jovanovic and J. K. Harris. Systems and software assurance #8212; a
modcl cyucr i:;ccurity couri:;c. Iu 2016 :J9th Inteniational Co1wention 01t In
fonnation and Communication Technology, Electronics and Microelectronics
(MIPRO), pages 923 -927, ~lay 2016.
[23] l\f. Junjin. An approach for sql injection vulnerability detection. In 2009
Sixth lntemational Conference on lnfonnation Technology: New Genera
tions, page8 1411-1414, April 2009.
[24] Adam Kieyzun, Philip J. Guo, Karthick Jayaraman, and l\Iichael D. Ernst.
A utomatic creation of sql injection and cross-si te scripting attacks. In Pro
ceedings of t.he 31st /nf(';n1n.f.fonal Confere.nce on Software Engin(';ering, ICSE
'09, pages 199-209, Washington, OC, CSA, 2009. IEEE Computer Society.
[25] Thales Sc•hn Kortinp;. C4.G alp;orithm an<l multivariate dcdsion trPC'S. Imagc
Processing Division. Nationn.l Institute for Space Research-INPE Sao lose
dos Campos-SP. Bm::il. 2006.
[26] P. Kumar and R. K. Pateri~·a. A survey on sql injection attacks, detection
aud preveulion lt•C'huiq11es. In Computing Communication Networking Tech-
1wlogic:s (JCCCNT), 2012 Thir·d lntcmational Conferenc:c 011. pag<-'l:i 1-:J,
Ju!~· 2012.
[27] Lei Liu . .Jiug Xu. Cheukai Guo . .Jidmi Kang, Sihau Xu, aud Diau Zhaug.
Exposing sql injedion vuhwrabilit~· throngh penetration test base<l on finite
:;t<1te machine. In 2016" 211d IEEE lntPmational Conference on Computr.r
mH/ Com·111·1mirn.tiow; (ICCC}. ¡mgt>~ 1171-1175, Oct 2016.
G3
[28] L. MacLeod. '.\l. Greiler, t-.I. A. Storey, C. Bird, and .J. Czerwonka. Code
rc•vi<'winp; in t.lw trenC'hes: Und<'rstaudinp; challeng<'s and lw:;;t practkcs. IEEE
Software, PP(99):1-1, 2017.
[29] Michael ?\Iartin, Benjamín Livshits, and l\fonica S. Lam. Fin<ling application
errors aud seC'urity flaws using pql: A prograrn query language. SJGPLAN
Not., 40( 10):3G5-383, Oct.ob<'r 2005.
[30] T. Matsuda, D. Koizumi, M. Sono<la, an<l S. I-lirn.sawa. On pr<'<lictivc Nrors
of sql injection attack detection by the feature of the single character. In
2011 IEEE lnternational Conference on Systems, Man, and Cybernetics,
pagcs 1722-1727. Oct 2011.
[31] íl .A. ;\kClnr<' an<l I.H. Krng<'r. Sql dom: compile tinw dw<'king of dyuamk
sql statements. 06 2005.
[32] l\.fsdn.microsoft.com. ¿qué es windows communication foundation?,
https://msdn.microsoft.com/es-es/library/ms731082{v=vs.110).aspx, 2015.
[33] Anh Nguyen-Tuong, Salvatore Guarnieri, Doug Greene, Jeff Shirley, a.nd Da
vid Evans. Antom.atir.a.lly Ha.rdcn.in.g Web Applir.a.tion.8 Using I'rer.isr Ta.in.
ting, pages 295-307. Springer US, Boston, MA, 2005.
[3-1] Y. Park and J. Park. Web application intrusion detection system for input
vali<lation attack. In 2008 Third lntemational Conference on Com•ergence
mu/ Ilybrid b~/ón1wtiou Tedmology, volumc 2, pagcs 498-50-1, Nov 2008.
[35] Tarlensz Pi<'tra:-;:r.ck and Chris Vandcn Dcrghc. Dcfcnding Again.~t fo]rr·tion
A ttad:s Thro 11.gh Conte.1:t-Srn.sitfoe String Evaluation, pagcs 12-1-1-10. Spri 11-
ger Berlín Heidelberg, Berlín, Heidelberg, 2006.
[3G] Chen Piug. \Vang Jinslmang, Pan Lin, and Yu Han. Resea.rch ami irnplemPll
tatiou of sql iuj<'diou prcYentiou metho<l base<l ou isr. Iu :!Olú' :!11.1/ IEEE
ln.tcrn.ational Co11jf'1·ena on Computer an.d Communirn.tions (Trrr.). pagPs
1Ei3 115G, Oct 2016.
[37] J. R. Quinlan. lnduction of deciRion t.rc<'s. Mach. Lcarn., 1(1):81--106, Mard1
Hl8G.
[38] S. Rauti, .T. Tmhola, an<l V. L<'pp~inm. Div<'rsifyinp; R<]I t.o pr<'V<'llt inj<'ction
attacks. In 2015 IEEE Trustcom/BigDataSE/ISPA. volume l, pages 344-
35L Aug 2015.
[39] Sqlmap. Sqlmap. http:í /sqlmap.org/, 2015.
[40] Zhendong Su and Gary Wassermann. The essence of command injection a.t
tac·k.s in wch applications. In Conferen.r.e Rer.ord of the. .'l.'lrd ACM SIGPLAN
SIGACT Symposium on Principies of Programming Languages, POPL '06,
pages 372-382, Ne\v York, NY. USA, 2006. ACM.
[41] Gary Wassermann and Zhendong Su. An analysis framework for security iu
W<'h applimtion.s. 09 2017.
