Documento - Inicio - Universidad de Guadalajara

UNIVERSIDAD DE GUADALAJARA
CENTRO UNIVERSITARIO DE CIENCIAS ECONÓMICO ADMINISTRATIVAS
COORDINACIÓN DE POSGRADOS
MAESTRÍA EN TECNOLOGÍAS DE INFORMACIÓN
“EFECTIVIDAD DE TÉCNICAS DE OWASP PARA ASEGURAR APLICACIONES WEB
CONTRA INYECCIÓN DE SQL”
QUE PARA OBTENER EL GRADO DE:
MAESTRO EN TECNOLOGÍAS DE INFORMACIÓN
PRESENTA:
MANUEL LÓPEZ ARREDONDO
DIRECTOR:
MTRO. LUIS ALBERTO MACIEL ARELLANO
ZAPOPAN, JALISCO A XXX XX DEL XXXX
Dedicatoria
Mis padres que me dieron la mejor herencia que un hijo puede pedir: amor, apoyo y
educación.
i
Agradecimientos
Mi más sincero agradecimiento al Mtro. Luis Maciel por invertir parte de su valioso
tiempo en dirigir éste trabajo de investigación; sin su apoyo sería complicado concluir una
tesis de ésta calidad.
ii
Resumen
El presente documento muestra un estudio del nivel de riesgo al que se encuentran
expuestas todo tipo de instituciones, empresas privadas y gobiernos por medio de sus
aplicaciones web, ya sea sitios internos (intranet) o externos (internet), mediante la
explotación de las vulnerabilidades de inyección de SQL, así como del nivel de efectividad
de las técnicas de OWASP (Open Web Application Security Project) para mitigar ésas
vulnerabilidades.
Por medio de la ejecución de pruebas de penetración enfocadas a explotar las
vulnerabilidades mencionadas, y con base a una evaluación de las prácticas de desarrollo
seguro de software de la organización objetivo, tendremos un panorama inicial del estado
de la seguridad de la aplicación, y obtendremos el nivel de madurez de las prácticas de
desarrollo de software seguro de la organización; para después, implementar las técnicas
de OWASP, realizar el mismo ejercicio, e identificar si éstas técnicas son efectivas
mediante la comparación de resultados. Lo anterior con la finalidad de ayudar a los
profesionales de Seguridad de la Información, Desarrolladores de Software y
Organizaciones en general, a tomar decisiones más informadas para mitigar riesgos de
integridad y confidencialidad de la información en aplicaciones web.
iii
Contenido
INTRODUCCIÓN ................................................................................................................. 1
ASPECTOS PRELIMINARES ................................................................................................... 3
Planteamiento del Problema................................................................................................. 4
La fundación OWASP ............................................................................................................ 9
Objetivos de Investigación .................................................................................................. 11
1.1.1 Objetivos Generales ........................................................................................................ 11
1.1.2 Objetivos Específicos ....................................................................................................... 11
1.1.3 Hipótesis .......................................................................................................................... 12
CONTRIBUCIÓN ..................................................................................................................... 12
COMPARACIÓN CON TRABAJOS ANTERIORES .............................................................................. 13
MARCO TEÓRICO ............................................................................................................ 15
Terminología Elemental ...................................................................................................... 16
Ataques de Inyección de SQL .............................................................................................. 17
1.1.4 Pruebas de Caja Negra..................................................................................................... 18
1.1.5 Herramientas ................................................................................................................... 20
Técnicas OWASP ................................................................................................................. 26
1.1.6 OWASP Top Ten ............................................................................................................... 27
1.1.7 Enterprise Security API (ESAPI) ........................................................................................ 29
1.1.8 AppSensor........................................................................................................................ 30
1.1.9 Application Verification Security Standard (ASVS) .......................................................... 32
1.1.10 OWASP Testing Guide.................................................................................................... 35
1.1.11 OWASP Software Assurance Maturity Model (SAMM) ................................................. 36
Método .............................................................................................................................. 37
CASOS DE ESTUDIO .......................................................................................................... 40
CONCLUSIONES ............................................................................................................... 41
Resultados ......................................................................................................................... 42
Discusión ............................................................................................................................ 42
Conclusiones ...................................................................................................................... 42
Trabajo Futuro.................................................................................................................... 42
REFERENCIAS .................................................................................................................. 43
iv
Lista de Figuras
Figura 1 Costo anual promedio de un ciber ataque (Ponemon Institute, 2012)............................ 4
Figura 2 Vulnerabilidades por trimestre 2005-2012 (The Open Source Vulnerability Database,
2012)........................................................................................................................................ 6
Figura 3 Vulnerabilidades mas comunes en OSVDB por categoría 2000-2012 (Hewlett-Packard,
2012)........................................................................................................................................ 6
Figura 4 Relación de OWASP con otros estándares y regulaciones ............................................ 10
Figura 5 Aplicación Web de Arquitectura de cuatro capas ........................................................ 17
Figura 6 Ilustración del ataque de inyección de SQL (Hewlett-Packard, 2012) ........................... 19
Figura 7 WSDigger .................................................................................................................. 20
Figura 8 Falcove ...................................................................................................................... 22
Figura 9 NMAP ....................................................................................................................... 24
Figura 10 Metasploit Pro ......................................................................................................... 26
Figura 11 Cambios en el OWASP Top 10 de 2010 contra 2013 (Williams & Wichers, 2013) ........ 27
Figura 12 Criterios de evaluación de riesgos de OWASP (OWASP, 2011) ................................... 28
Figura 13 Cuadro de análisis de riesgos para las vulnerabilidades de inyección (Williams &
Wichers, 2013) ....................................................................................................................... 28
Figura 14 Ejemplo de implementación de ESAPI (OWASP, 2011)............................................... 29
Figura 15 Contenido del reporte de la revisión de seguridad (OWASP, 2009) ............................ 35
Figura 16 Modelo SAMM (Chandra & Deleersnyder, 2012) ....................................................... 37
v
Lista de Tablas
Tabla 1 Ejemplos de Casos de Inyección de SQL en los últimos años ........................................... 7
Tabla 2 Puntos de detección por cada excepción en AppSensor (Watson & Coates, 2010) ......... 31
Tabla 3 Niveles de tolerancia para cada tipo de respuesta (Watson & Coates, 2010) ................. 32
Tabla 4 OWASP ASVS Requerimientos de Validación de Captura (V5) (OWASP, 2009) .............. 38
vi
INTRODUCCIÓN
“El costo total del Cibercrimen es mayor que el efecto combinado que tiene el tráfico de
marihuana, heroína y cocaína sobre la economía global.” (Parnell, 2011)
En un estudio del SANS Institute se menciona que el 60% de los ataques en
Internet se hacen contra aplicaciones Web (Scholt, Balzarotti, & Kirda, 2012); en
consecuencia, cualquier organización está expuesta al robo de datos e incluso a
problemas de integridad de los mismos, llevando a la organización a enfrentar riesgos
regulatorios, de reputación y legales. En el caso de México, un ejemplo de un riesgo legal
es el no cumplimiento de la Ley Federal de Protección de Datos en Posesión de
Particulares (LFPDPPP), que describe como motivo de incumpliendo con la regulación, el
hecho de “Vulnerar la seguridad de bases de datos, locales, programas o equipos, cuando
resulte imputable al responsable”; las sanciones van desde 100 hasta 320,000 días de
salario mínimo (Diario Oficial de la Federación, 2010).
Los ataques de Inyección de SQL son realizados al enviar código malicioso sobre
aquellos campos que se encuentran a la vista del usuario; vía la sintaxis del código
enviado, se puede explotar al intérprete de base datos. Por ejemplo, existen
combinaciones de caracteres que pueden tener un significado especial para el manejador
de la base de datos o RDBMS ya que estos caracteres son parte del lenguaje del
manejador de base de datos. Los siguientes caracteres son un ejemplo de estos caracteres
especiales:

‘ o “ (caracteres que indican cadenas de texto)

# (línea simple comentada)

/* … */ (varias líneas comentadas)

+ (suma o concatencación)

% (indicador para varios caracteres)
1
Al enviar a la aplicación una combinación de los caracteres arriba mostrados, un
atacante puede tener acceso para consultar o manipular la información, al enviar
comandos de SQL.
El Proyecto Abierto de Seguridad en Aplicaciones Web (OWASP por sus siglas en
inglés) provee algunas soluciones para fortalecer la seguridad en aplicaciones web y
mitigar el riesgo de que la inyección de SQL sea encontrada y explotada.
El propósito de éste estudio de caso es trabajar en la implementación de las
técnicas OWASP en organizaciones mexicanas realizando las siguientes tareas:

Capacitar a las organizaciones en la implementación de Técnicas OWASP ya sea en
línea o en sitio.

Identificar las aplicaciones dentro del alcance por cada organización.

Implementar las técnicas de OWASP en las aplicaciones dentro del alcance.

Medir los resultados mediante:
o Indicadores clave de riesgo (KRI por sus siglas en inglés): Número y nivel de
riesgo de las vulnerabilidades encontradas por un ejercicio de prueba de
penetración, antes y después de la implementación de las técnicas OWASP.
o Evaluación del nivel de madurez de la organización para el desarrollo
seguro de software, antes y después de la implementación de las técnicas
OWASP.
2
Capítulo I
ASPECTOS PRELIMINARES
“Muchas de las mas serias y comunes vulnerabilidades en software, se deben a
errores bien conocidos que son fáciles de encontrar y fáciles de explotar” (CWE/SANS,
2011)
3
Planteamiento del Problema
Los ataques cibernéticos son descritos por (Tatum, 2013), como un intento de
comprometer la funcionalidad un sistema de computación, o como un intento de rastrear
las transacciones en línea de un individuo sin tener su permiso. Éste tipo de ataques
pueden pasar sin ser percibidos por el usuario final, y también pueden llevar a la red a un
estado en el que no está en funcionamiento, de tal forma que ninguno de los usuarios
pueda realizar incluso las tareas más básicas.
El primer incidente registrado de un ataque cibernético se dio en 1966 cuando un
atacante modificó datos del Banco de Minnesota; y fue hasta 1977 cuando el senador
Ribicoff de Estados Unidos creó la ley Federal de Protección de Sistemas Computacionales
(Harris, 2008).
Actualmente, el costo total de un ataque cibernético va desde $3,252,912 USD
hasta $8,933,510 USD (Ponemon Institute, 2012). La siguiente figura muestra el
porcentaje anualizado del costo de los ciber ataques por tipos de ataque; donde podemos
ver que los “Malicious code” se encuentra en el primer lugar. El reporte distingue a los
ataques de Inyección de SQL dentro de ésta categoría.
Figura 1 Costo anual de un ciber ataque (Ponemon Institute, 2012)
4
El estudio contempló entre otro tipo de ataques, a las inyecciones de SQL dentro
de la categoría “Web-based attacks”.
Las vulnerabilidades en las aplicaciones web siguen siendo populares debido a la
falta de atención por parte de las organizaciones y desarrolladores de software para
evitarlos (Hewlett-Packard, 2012). Resulta impresionante saber que a un atacante le
bastan sólo 7 horas para encontrar una vulnerabilidad en una aplicación web, con un 95%
de certeza en el hallazgo (Holm, Ekstedt, & Sommestad, 2013).
5
La siguiente figura ilustra las vulnerabilidades reportadas por trimestre desde 2005
hasta 2012 demostrando que las vulnerabilidades de Inyección de SQL han sido una de las
más constantes a lo largo de los años (The Open Source Vulnerability Database, 2012).
Figura 2 Vulnerabilidades por trimestre 2005-2012 (The Open Source Vulnerability Database, 2012)
Finalmente, la figura de abajo, muestra las 6 vulnerabilidades más comunes, de las
cuales cuatro impactan a las aplicaciones web, representando el 40% de las
vulnerabilidades reportadas (The Open Source Vulnerability Database, 2012; HewlettPackard, 2012).
Figura 3 Vulnerabilidades mas comunes en OSVDB por categoría 2000-2012 (Hewlett-Packard, 2012)
6
Sin embargo, el universo de los ataques a aplicaciones web es grande y no sería
posible evaluar todos ellos como alcance de éste estudio de caso. Por lo anterior, nos
enfocaremos en el ataque más común y con más nivel de riesgo en aplicaciones web: la
inyección de SQL (Williams & Wichers, 2013).
No resulta claro cuándo fue la primera vez que un ataque de SQL se presentó, sin
embargo el crédito se ha dado a Rain Forest Puppy quien en 1998 hizo público cómo
funcionan estos ataques al describirlos en su artículo (Puppy, 1998). Desde entonces y
como hemos analizado anteriormente, ha sido uno de los ataques más constantes; como
se muestra en la siguiente tabla, estos son solo algunos de los ejemplos de aquellos casos
en que la inyección de SQL fue utilizada como medio de explotación en una aplicación web
(Clarke, 2012):
Tabla 1 Ejemplos de Casos de Inyección de SQL en los últimos años
Fecha
Febrero 2002
Descripción
Jeremiah Jacks explotó la vulnerabilidad en el sitio guess.com
obteniendo acceso a datos de tarjetas de crédito de 200,000 clientes.
Junio 2003
Jeremiah Jacks de nuevo utilizó inyección de SQL en petco.com para
obtener acceso a datos de 500,000 tarjetas de crédito.
Junio 2005
Master Card reportó el ataque de inyección de SQL más grande del
momento al mencionar que 4 millones de registros de tarjetas de
crédito fueron robados por un hacker.
7
Diciembre 2005
La empresa EnCase fue atacada por inyección de SQL y perdió datos
financieros de aproximadamente 3,800 clientes.
Diciembre 2006
Hackers robaron a TJX millones de registros de datos de sus clientes
con detalles de sus tarjetas de crédito.
Agosto 2007
La página inicial del sitio de las naciones unidas fue cambiada por un
hacker mostrando mensajes en contra de los Estados Unidos.
2008
El botnet Asprox utilizó vulnerabilidades de inyección de SQL en sitios
web para expandir el malware alrededor del mundo. El número de
páginas web atacadas se estima que fue alrededor de 500,000.
Febrero 2009
Un grupo de hackers romanos se atribuyó varios ataques utilizando
inyección de SQL a sitios web de compañías como Kaspersky, F-Secure
y Bit-Defender
Agosto 2009
El Departamento de Justicia de Estados Unidos sentenció al ciudadano
americano Albert Gonzalez por el robo de 130 millones de números de
tarjetas de crédito utilizando inyección de SQL.
Abril 2011
Barracuda Networks sufrió un ataque de inyección de SQL y el hacker
hizo público los registros de sus clientes incluyendo usuarios y
passwords.
Mayo 2011
LulSec comprometió el sitio web de Sony por medio de inyección de
SQL, de acuerdo a la prensa, el grupo hacktivista obtuvo acceso a
contraseñas, correos electrónicos, dirección particular y fechas de
nacimiento de alrededor de un millón de usuarios. Adicionalmente,
obtuvo 3.5 millones de cupones de música de su sitio.
Diciembre 2012
El proyecto WhiteFox es un esfuerzo del hacktivismo para promover el
tránsito libre de la información. Por medio de inyección de SQL ha
obtenido acceso a 1.6 millones de registros de diversas organizaciones
como la NASA, FBI, Interpol y el Pentágono. Los tipos de datos
obtenidos son nombres, correos electrónicos, direcciones particulares
entre otros, que fueron hechos públicos en Internet.
8
Julio 2012
Uno de los más grandes robos de información por medio de inyección
de SQL se dio en Alemania cuando el hacker “8in4ry_Munch3r” tuvo
acceso a credenciales de usuarios de Gamigo al obtener 11 millones de
contraseñas encriptadas y 8.2 millones de correos electrónicos.
Además de los impactos arriba mencionados, se estima que el impacto económico
de un ataque de inyección de SQL es de $2.2 billones de dólares (Morana & Ucedavelez,
2009).
La fundación OWASP
La fundación OWASP surgió en 2001 debido a la necesidad de contar con un
estándar de la industria de la seguridad para desarrollar una metodología para hacer
pruebas de seguridad en aplicaciones web. Sus miembros desde un inicio y hasta la fecha
hacen aportaciones voluntarias ya sea con fondos económicos, desarrollando proyectos,
software y documentación en nombre de la fundación, así como en la difusión del
material mencionado.
OWASP es una fundación no lucrativa cuyo principal propósito es proporcionar a la
industria de la seguridad información material que ayude a las organizaciones y
profesionales a tomar decisiones informadas cuando haya que aplicar controles de
seguridad en aplicaciones web.
El material desarrollado por la fundación es libre y el código es abierto, de tal
forma que puede ser obtenido por cualquier persona e incluso puede ser mejorado
dependiendo de las necesidades de cada organización. El software generado por OWASP
se puede distribuir bajo la licencia de software libre.
La influencia de OWASP en la industria se determina bajo 4 factores:
9

Citaciones en la industria: Instituciones gubernamentales de diversos países y
organismos internacionales hacen referencia a material desarrollado por OWASP
para implementar controles de seguridad en aplicaciones web.

Proyectos desarrollados: Más de 400 proyectos entre documentos, herramientas,
ambientes de aprendizaje, guías y otros materiales que ayudan a las
organizaciones a mejorar su capacidad de desarrollar código seguro.

Patrocinadores: A nivel global, organizaciones como IBM, HP, ORACLE, Symantec,
entre otros, así como varias Universidades alrededor del mundo apoyan a la
fundación ya sea por medio de donativos económicos, apoyando eventos como
conferencias o reuniones de capítulo, ofreciendo capital intelectual para el
desarrollo de proyectos, por mencionar algunos.

Capítulos Locales de OWASP: Los capítulos locales ofrecen la posibilidad de realizar
eventos en cada ciudad con el fin de dar a conocer nuevas tendencias y proyectos
desarrollados por la Fundación así como a seguir generando conocimiento en
relación a la seguridad en aplicaciones web. Los eventos desarrollados por los
capítulos no tienen costo y cualquier persona puede atender las reuniones. Al día
de hoy hay más de 100 capítulos en todo el mundo.
OWASP está influenciado por otros estándares internacionales de seguridad de la
información como COBIT e ISO27001; por lo tanto “Es perfectamente correcto mezclar
y combinar controles de COBIT y de ISO 17799 y casi cualquier otro estándar de
seguridad de la información; rara vez se encuentran en desacuerdo en los detalles”
(van der Stock, 2005). La siguiente figura muestra una relación entre OWASP como
marco referencia contra otros estándares y regulaciones internacionales en materia de
seguridad de la información:
Figura 4 Relación de OWASP con otros estándares y regulaciones
10
Objetivos de Investigación
1.1.1 Objetivos Generales
Evaluar la efectividad de la aplicación de técnicas de OWASP para la protección
contra ataques de inyección de SQL.
1.1.2 Objetivos Específicos
Los objetivos particulares de la tesis son:

Ejecutar ataques de Inyección de SQL a objetivos específicos.

Obtener las métricas de riesgo tales como el número total de
vulnerabilidades identificadas así como su clasificación de riesgo con base a
OWASP.
11

Implementar técnicas de OWASP, a las aplicaciones web objetivo y a la
organización objetivo.

Una vez que las técnicas OWASP han sido implementados, ejecutar las
mismas técnicas y script de ataques a los mismos objetivos.

Obtener las métricas de riesgo, y el nivel de madurez; para evaluar si el
número de vulnerabilidades y su respectivo nivel de riesgo, cambió con
base al ejercicio inicial.

Presentar los resultados en conferencias y revistas especializadas.
1.1.3 Hipótesis

La implementación de técnicas OWASP en aplicaciones web disminuye el
número de vulnerabilidades encontradas por un ataque de inyección de
SQL.

La implementación de técnicas OWASP en aplicaciones web disminuye el
nivel de riesgo de las vulnerabilidades encontradas por un ataque de
inyección de SQL.
CONTRIBUCIÓN
Más allá de validar la efectividad de las técnicas de OWASP, la tesis proveerá casos
prácticos de éxito a los proyectos OWASP que serán utilizados dentro de la investigación,
esto con el objetivo de incrementar y difundir no sólo la misión de la fundación, sino
también crear conciencia de la importancia de la seguridad de la información en las
aplicaciones web, dentro de las empresas de la ciudad de Guadalajara.
Adicionalmente, la participación y aportación de casos prácticos a los proyectos
OWASP, ayudará a que los proyectos sean promovidos dentro de la fundación OWASP y
en consecuencia citados en la industria por otras instituciones.
12
COMPARACIÓN CON TRABAJOS ANTERIORES
La revisión de la bibliografía nos permite identificar trabajos similares aunque con
diferentes enfoques, como el de (Rodriguez Argueta, 2011) que hace un análisis del
estado de la seguridad de las aplicaciones con dominios .gob.mx; el trabajo se enfoca en
evaluar la seguridad con base a estándares internacionales, como el de OWASP, y a
proponer técnicas de pruebas de penetración en las aplicaciones. Sin embargo, no lleva la
implementación de dichas técnicas a la práctica.
El trabajo realizado por (Ramirez Lopez, 2009) propone una marco de control
basado en estándares internacionales como la ISACA y el NIST, para analizar las
vulnerabilidades en sistemas operativos, y para realizar pruebas de penetración a los
mismos. El trabajo, además de que el enfoque es en sistemas operativos y no en
aplicaciones web, tampoco lleva a cabo la implementación del esquema propuesto.
El estudio realizado por (Saenz Gonzalez, 2009), es lo más apegado que se pudo
encontrar, ya que indica los requerimientos y las guías para la construcción de un
laboratorio para pruebas de penetración y análisis de vulnerabilidades con base al NIST.
Sin embargo, no lleva a cabo la práctica de las pruebas de penetración en un escenario
real, además la investigación se enfoca a las pruebas sobre redes de computadora y no a
las aplicaciones web.
La investigación de (Carreon Mendoza, 2009), propone una estrategia para el
desarrollo seguro de software de una paraestatal mexicana, sin embargo no lleva la
estrategia a la práctica y no menciona bajo qué estándares se construye dicha estrategia.
El trabajo mas apegado a nuestra investigación es el realizado por (Dharam &
Shiva, 2012) quienes proponen una técnica de monitoreo contra ataques de inyección de
SQL; ésta metodología se basa en un marco de control llamado “Runtime Monitoring” que
13
consiste en la evaluación de todos las posibles combinaciones de ataques que pueden
representar un ataque de inyección de SQL. Llevaron el enfoque a la implementación y lo
probaron con base a una serie de ataques básicos predefinidos, en los cuales, la
implementación demostró que identificó exitosamente todos los ataques llevados acabo.
Como parte del trabajo futuro, (Dharam & Shiva, 2012) proponen incrementar las
reglas de ataques de inyección de SQL dentro de su enfoque para que éste sea capaz de
identificar todos los posibles ataques que actualmente se llevan a cabo.
La diferencia principal de nuestro estudio con respecto a éste último trabajo, es
que nosotros estaremos probando la efectividad de las técnicas de OWASP en un
ambiente real, bajo circunstancias lo más reales posibles y basándonos en herramientas
automáticas y técnicas manuales, lo cual implica que el alcance de nuestras pruebas será
más amplio, ya que la investigación de (Dharam & Shiva, 2012) sólo se enfoca en un
limitado conjunto de reglas de ataques de inyección de SQL.
14
Capítulo II
MARCO TEÓRICO
“Los ciberataques pueden llegar a ser devastadores, y sus efectos son cercanos a
los que causan las armas de destrucción masiva.” (Levin, 2010)
15
Terminología Elemental
A continuación daremos un breve repaso a los conceptos básicos de seguridad de
la información para establecer un lenguaje común de acuerdo a (EC-Council, 2011):

Amenaza: Una acción o evento que podría comprometer la seguridad. Una
amenaza es una potencial violación de la seguridad.

Vulnerabilidad: Existencia de una debilidad, diseño, o error de
implementación que puede llevar a que un evento no deseado, o no
esperado, comprometa la seguridad del sistema.

Sistema Objetivo: Un sistema, producto o componente de Tecnología de
Información (TI) que es objeto de una evaluación de seguridad de la
información.

Ataque: Un asalto a la seguridad del sistema resultado de una amenaza. Un
ataque es cualquier acción que viola la seguridad del sistema.

Explotación: Una forma definida de romper la seguridad de un sistema de
TI a través de una vulnerabilidad.

Riesgo: Es la Probabilidad de que una amenaza tome ventaja de una
vulnerabilidad que impacte al negocio (Harris, 2008).

Controles: Medidas que son implementadas para mitigar un riesgo (Harris,
2008).
Por otro lado, los elementos fundamentales que forman la seguridad de la
información según (Harris, 2008) son:

Disponibilidad: Confiabilidad de que los datos y los recursos pueden ser
accedidos por personas autorizadas.

Integridad: Asegura la exactitud y confiabilidad de la información y de los
sistemas; y cualquier modificación es prevenida y autorizada.
16

Confidencialidad: Asegura el nivel necesario de secreto a cada parte de los
datos y previene la fuga de información.
Es importante dejar en claro que las pruebas de penetración son los procesos de
simular un ataque sobre la red o los sistemas, bajo la petición del dueño y de la alta
gerencia de una organización. El objetivo es medir el nivel de resistencia que tiene una
aplicación web contra un ataque, así como descubrir cualquier vulnerabilidad en el
ambiente (Harris, 2008).
Ataques de Inyección de SQL
Una aplicación web es un conjunto de páginas que son generadas como respuesta
a una petición del usuario. En internet existen muchos tipos de aplicaciones web tales
como motores de búsqueda, tiendas en línea, periódicos y revistas en línea, foros de
discusión, juegos, entre otros. (Murach & Steelman, 2008)
Muchas de las aplicaciones web están soportadas por diferentes capas de
infraestructura para proporcionar su servicio, según (Clarke, 2012), una arquitectura
compleja puede representarse como muestra la Figura 4
Figura 5 Aplicación Web de Arquitectura de cuatro capas
17
Donde la capa de presentación es la capa que ve el usuario final y donde interactúa
con la aplicación para obtener datos o un servicio. La capa lógica realiza las operaciones
de programación y contiene los llamados a los servicios que se encuentran en la capa de
aplicación, estos servicios contienen actividades específicas de procesamiento
dependiendo de las instrucciones enviadas por la capa lógica para finalmente almacenar
datos en la capa de almacenamiento, o servidores de Bases de Datos.
Los ataques de inyección de SQL funcionan al enviar código en cualquier campo de
texto de la aplicación cuya intención es permitir al usuario final enviar información a la
base de datos; estos son puntos de entrada de la aplicación. Al enviar código a través de
éstas vías de entrada, el código es interpretado por la base de datos, ejecuta los
comandos enviados, y regresa la información al usuario final o atacante (Meucci, Keary, &
Cuthbert, 2008).
Los ataques de inyección SQL están divididos en las tres siguientes clases (Meucci,
Keary, & Cuthbert, 2008):

Inband: los datos son extraídos usando el mismo canal que es usado para inyectar
el código SQL. Este es el tipo de ataque más simple, en el que los datos recibidos se
muestran en la propia aplicación web.

Out-of-band: los datos son extraídos usando un canal diferente (por ejemplo, un
correo con el resultado de la consulta es generado y enviado al atacante).

Inferential: no hay transferencia de datos, pero el atacante puede reconstruir la
información enviando peticiones y observando el comportamiento que mantiene
el servidor de bases de datos.
1.1.4 Pruebas de Caja Negra
El primer paso en esta prueba es entender cuando la aplicación conecta a un
servidor de bases de datos para acceder a algún dato (Meucci, Keary, & Cuthbert, 2008).
18
Un atacante debe probar todos los campos que pueden ser usados para crear una
consulta SQL, incluyendo los campos ocultos de una petición POST y entonces probarlos
por separado, intentando modificar la consulta real y producir un error. La prueba más
básica consiste en añadir una comilla simple (‘) o un punto y coma (;) al campo que se
quiere probar. El segundo paso es el fin de una sentencia SQL y, si no está filtrado, puede
generar un error.
Un mensaje de error, ofrece una gran cantidad de información al atacante con el
fin de crear una inyección con éxito. Sin embargo, las aplicaciones podrían no enviar
mucho detalle; como puede ser el acaso de obtener un mensaje tipo: “500 Server Error” o
una página de error diseñada por el programador para evitar que estos mensajes de error
del sistema sean enviados, lo que significa se deben utilizar técnicas de inyección SQL
ciega (Blind SQL Injection).
Un ejemplo de un ataque utilizando la barra de dirección en un explorador de
Internet, es enviar comandos SQL por el método GET, y si el dominio de la aplicación web
es vulnerable, la petición sería la siguiente:
http://www.victima.com/index.php?username=1'%20or%20'1'%20=%20'1&passw
ord=1'%20or%20'1'%20=%20'1
El ataque de inyección ciega de SQL (Blind SQL inyection) demanda mucho tiempo
y varias peticiones al servidor, para poder ser exitoso y explotar la inyección de SQL. Por lo
tanto, el uso de herramientas automatizadas que faciliten ésta tareas es muy común y en
la siguiente sección analizaremos algunas de ellas.
Figura 6 Ilustración del ataque de inyección de SQL (Hewlett-Packard, 2012)
19
1.1.5 Herramientas
WSDigger
Es una herramienta de software libre utilizada para automatizar pruebas de
penetración; fue diseñada por McAfee Foundstone. Contiene plug-ins para evaluar
vulnerabilidades, entre otras, la de inyección de SQL (McAfee Foundstone).
Figura 7 WSDigger
20
Acunetix Web Scanner
Acunetix Web Scanner determina si una aplicación web contiene vulnerabilidades
como la de inyección de SQL, las principales características según (Acunetix Ltd) son:

Verifica la complejidad de las contraseñas durante la autenticación de las
páginas del tipo HTML o HTTP.

Garantiza seguridad.

Revisa el contenido dinámico de una página web, como las formas.

Soporta la mayoría de las tecnologías, incluyendo ASP, ASP.NET, PHP y CGI.

Descubre directorios con permisos débiles.
21

Determina si hay métodos de HTTP peligrosos, habilitados en un servidor
web.

Reporta si en la aplicación web se encontraron vulnerabilidades del OWASP
Top 10.
AppScan
AppScan es una herramienta que evalúa la seguridad de un sitio web por medio de
pruebas de seguridad. Primero explora todo el sitio web para identificar todas las páginas
y componentes que le dan forma; posteriormente ejecuta pruebas de vulnerabilidad
masivas incluyendo la inyección de SQL (SC Magazine, 2007).
Falcove
Es una herramienta de escaneo de vulnerabilidades que ayuda a identificar si un
sitio web es vulnerable. Audita los contenidos dinámicos de las páginas incluyendo los
campos para ingreso de contraseñas, carritos de compras y otras aplicaciones web.
Finalmente genera reportes de vulnerabilidades indicando el estado del sistema. (SoftPile,
2008)
Figura 8 Falcove
22
WebInspect
La herramienta proporciona el conocimiento para identificar rápidamente
vulnerabilidades críticas en aplicaciones web. Realiza simulación de ataques externos,
para posteriormente analizar la información contra el código interno de la aplicación, para
evaluar qué vulnerabilidades se pueden estar explotando en tiempo real. Ayuda al
cumplimiento de regulaciones y estándares de seguridad como OWASP (HP Web Inspect,
2013).
McAfee WAAM
McAfee Web Application Assessment Module (WAAM) ofrece un escaneo
profundo de las aplicaciones web asegurando que los errores comunes de codificación
23
sean corregidos como parte del proceso de administración de vulnerabilidades. Sus
revisiones incluyen identificación de inyección de SQL y los reportes ayudan al
cumplimiento de regulaciones y están apegados a estándares de seguridad como el
OWASP Top 10 (McAfee Inc, 2012).
SQLiX
Es una herramienta de software libre cuyo propósito es encontrar vulnerabilidades
de inyección de SQL en aplicaciones web. Está basado en scripts de Perl y ofrece la
posibilidad de escanear sólo una página web por ejecución (OWASP, 2011).
SQLmap
Es una herramienta de software libre para la realización de pruebas de penetración
orientadas a identificar y explotar vulnerabilidades de inyección de SQL en aplicaciones
web ( Assumpcao Guimaraes & Stampar, 2012).
NMAP
NMAP es una herramienta que utiliza scripts para el escaneo de puertos en un
servidor; la última versión de nmap permite al usuario realizar un ecaneo de
vulnerabilidades sobre bases de datos SQL Server. Por medio de ésta versión de nmap es
posible escalar privilegios en SQL, obtener nombres de tablas y registros, evaluar
complejidad de las contraseñas, entre otras vulnerabilidades. NMAP es una herramienta
de software libre que normalmente corre en un sandbox como Backtrack o Metasploit.
Figura 9 NMAP
24
SQLNinja
Es una herramienta de software libre orientada a identificar y explotar
vulnerabilidades de inyección de SQL en bases de datos de Microsoft SQL Server. Sus
comandos tienen la capacidad de proporcionar acceso remoto completo a la base de
datos de la aplicación web que está siendo analizada. Se requiere Metasploit y módulos
adicionales de PERL para poder utilizarla (icesurfer & nico, 2012).
Zed Proxy Attack (ZAP)
ZAP es una herramienta de software libre para la ejecución de pruebas integradas
de penetración. Principalmente hace análisis de tráfico y funciona como un Proxy entre
dos puntos de conexión en una red. Al estar en medio de la comunicación, además de
analizar el tráfico en la comunicación, la puede atrapar y permitir al usuario modificar los
parámetros que serán enviados al otro punto de conexión, que normalmente es un
servidor. Es útil para la identificación de páginas web que potencialmente pueden tener la
25
vulnerabilidad de inyección de SQL; pero no tiene la capacidad de explotarla (OWASP,
2013).
Metasploit Pro
Herramienta que realiza pruebas de penetración sobre aplicaciones web; tiene la
versión Pro con interfaz gráfica y soporte directo del proveedor; también tiene la versión
de software libre, que es a base de líneas de comando y las actualizaciones y soporte son
manuales y proporcionados por la comunidad. La revisión de las vulnerabilidades cumple
con el OWASP Top 10.
Figura 10 Metasploit Pro
Técnicas OWASP
Hasta ahora hemos descrito cómo se pueden ejecutar los ataques de inyección de
SQL así como diversas herramientas disponibles, tanto comerciales como de software
libre, que pueden ser útiles para la identificación y explotación de la vulnerabilidad.
26
A continuación, describiremos las técnicas que OWASP tiene disponibles para
realizar análisis de vulnerabilidades en aplicaciones web así como los controles que la
fundación ha desarrollado para mitigarlos. Éstas serán la base para la implementación del
estudio de caso.
1.1.6 OWASP Top Ten
El proyecto OWASP Top 10 nació en 2003 con la finalidad de dar a conocer las
vulnerabilidades más comunes en aplicaciones web; es un compendio de diferentes
estándares y herramientas para identificar esas vulnerabilidades y proveer información
para poder mitigarlas. El objetivo principal de éste proyecto es hacer que los
desarrolladores de aplicaciones web y profesionales de seguridad de la información se
encuentren mejor informados y construyan aplicaciones web más seguras.
Los principales cambios en el Top 10 de la versión 2010 con respecto a la versión
2013 se muestran en la siguiente figura:
Figura 11 Cambios en el OWASP Top 10 de 2010 contra 2013 (Williams & Wichers, 2013)
27
La evaluación del riesgo se hace con base a la complejidad de encontrar y explotar
una vulnerabilidad en las aplicaciones web así como los posibles impactos para las
organizaciones. La siguiente figura nos ayuda a entender la metodología de OWASP para
la evaluación de los riesgos:
Figura 12 Criterios de evaluación de riesgos de OWASP (OWASP, 2011)
Con base al criterio ya mencionado, OWASP identificó las vulnerabilidades de
inyección como la vulnerabilidad número uno de su Top 10 debido a que el estudio
realizado demostró que la explotación de ésta vulnerabilidad no es compleja, es muy
común encontrarla en las aplicaciones web y los impactos son severos para las
organizaciones. La figura de evaluación de riesgos de OWASP para las vulnerabilidades de
inyección, se muestra de la siguiente figura:
Figura 13 Cuadro de análisis de riesgos para las vulnerabilidades de inyección (Williams & Wichers,
2013)
28
El proyecto OWASP Top 10 es un esfuerzo inicial y sugiere verificar otros proyectos
como el OWASP Testing Guide, el OWASP Application Security Verification Standard
(ASVS) y el OWASP Software Assurance Maturity Model (SAMM), con el objetivo de tener
más herramientas para un mejor manejo de riesgos en las vulnerabilidades de
aplicaciones web. A continuación estudiaremos algunos de estos proyectos.
1.1.7 Enterprise Security API (ESAPI)
El proyecto OWASP Enterprise Security API (ESAPI) es una librería de controles de
seguridad bajo la licencia de software libre que facilita a los desarrolladores de software
escribir aplicaciones de bajo riesgo. El diseño de ESAPI se compone de los siguientes
principios:

Contiene un conjunto de interfaces de control de seguridad. Estos definen los tipos
de parámetros que son pasados a cada tipo de control de seguridad.

Describe una referencia de implementación para cada control de seguridad. La
lógica no es orientada a una organización ni a una aplicación en particular.

Las implementaciones son opcionales y pueden adecuarse a las necesidades de la
organización para cada control de seguridad. El código del ESAPI puede ser
ajustado y modificado.
La ESAPI es una colección de clases que contienen controles clave de seguridad que
todas las aplicaciones necesitan. Las interfaces de control del ESAPI incluyen una clase tipo
ESAPI que es conocida como una clase localizadora. La clase localizadora ESAPI es llamada
con el propósito de regresar instancias individuales de controles de seguridad, que son
llamados a posteriori para realizar validaciones de seguridad. Un ejemplo de la
implementación de se puede apreciar en la figura siguiente:
Figura 14 Ejemplo de implementación de ESAPI (OWASP, 2011)
29
Naming conventions such as this are not
part of ESAPI but are good practice
$clean = array(); //this is local in scope
$clean_sql = array(); //this is local in scope
$clean['id'] = ESAPI::getValidator()->getValidInput( ... );
$clean_sql['id'] = ESAPI::getEncoder()->encodeForSQL( new MySQLCodec(), $clean['id']
Step 1
Step 2
);
This is also an
ESAPI control
Dentro de la ESAPI existen referencias de implementación de controles de
seguridad para cada uno de los siguientes tipos de control:
•
Authentication
•
Access control
•
Input validation
•
Output encoding/escaping
•
Cryptography
•
Error handling and logging
•
Communication security
•
HTTP security
•
Security configuration
1.1.8 AppSensor
El proyecto OWASP AppSensor, es un marco de referencia que tiene como objetivo
detectar actividad maliciosa dentro de la misma aplicación antes de que el usuario pueda
explotar una vulnerabilidad. Dado que las vulnerabilidades son explotadas por los
atacantes por medio de prueba y error, muchas vulnerabilidades no serían explotadas
dado que el AppSensor tomaría acciones preventivas con base a los tipos de ataques
identificados.
La arquitectura del AppSensor se compone de dos módulos:
30

Módulo de detección: Es responsable de identificar los comportamientos
maliciosos basado en las políticas definidas por el desarrollador. Los puntos de
detección pueden ser integrados dentro de la capa de presentación, la de negocios
y la de aplicación. El modulo de detección reporta las actividades al modulo de
respuesta.

Modulo de respuesta: La unidad de respuesta es una unidad que tomará acciones
en contra del usuario. La acción dependerá de si el evento es identificado como un
ataque o sólo un evento sospechoso así como del historial del usuario en relación a
actividades maliciosas y las políticas definidas para dar respuesta a esos eventos.
Los siguientes tipos de detección son configurados en el AppSensor; el número
total de puntos de detección está definido para cada tipo de detección. A continuación se
enumeran los tipos de detección así como el número de puntos de detección para cada
tipo:
Tabla 2 Puntos de detección por cada excepción en AppSensor (Watson & Coates, 2010)
Excepción
Requerimiento
Autenticación
Control de Acceso
Sesión
Entrada
Encodificación
Inyección de Comando
Archivo Entrada/Salida
Tendencia de Usuario
Tendencia de Sistema
# Puntos de
Detección
4
11
6
4
2
2
4
2
4
3
El valor del AppSensor se centra no sólo en la detección de actividad maliciosa sino
también en las acciones tomadas con base a la actividad identificada. Los tipos más
comunes de respuesta son mensajes de advertencia al usuario, logout, bloqueo de la
cuenta y notificación al administrador. Sin embargo, dado que el AppSensor está
31
conectado a la aplicación, las posibilidades de respuestas a una acción están limitadas por
las mismas capacidades de la aplicación.
Cuando se desarrollan las políticas de respuesta es crítico definir los niveles de
tolerancia apropiados para la respuesta a los eventos. El objetivo es disuadir posibles
ataques y actividad maliciosa al mismo tiempo que se minimizan los falsos-positivos
generados por actividades no maliciosas de los usuarios. La siguiente tabla muestra los
niveles de tolerancia recomendados para cada tipo de respuesta a ejecutar por el
AppSensor:
Tabla 3 Niveles de tolerancia para cada tipo de respuesta (Watson & Coates, 2010)
Eventos de
Sguridad
2
3
5
7
10
Acción de Respuesta
Mensaje de Violación de Seguridad
Mensaje de Violación de Seguridad + Logout
Mensaje de Violación de Seguridad + Bloqueo de la
cuenta por 5 minutos
Mensaje de Violación de Seguridad + Bloqueo de la
cuenta por 30 minutos
Notificación al Administrador + Bloqueo de la cuenta
indefinido
1.1.9 Application Verification Security Standard (ASVS)
El proyecto ASVS tiene como principal objetivo proporcionar un estándar para la
realización de pruebas de penetración en aplicaciones web. El estándar define cuatro
niveles jerárquicos con diferente alcance de rigurosidad; siendo el primer nivel el menos
riguroso y el cuarto el más exhaustivo.

Nivel 1 - Verificación Automática: Es la aplicada para aquellas aplicaciones en las
que cierta confidencialidad es requerida en el uso de controles de seguridad. El
alcance de éste nivel se enfoca a la revisión de código que fue desarrollado o
32
modificado para crear la aplicación. En éste nivel la verificación involucra el uso de
herramientas automáticas así como verificaciones manuales; se puede dividir en
1A para el uso de herramientas automáticas para el escaneo de vulnerabilidades
en la aplicación web y 1B para el uso de herramientas automáticas en la revisión
de código. Las técnicas manuales son sólo utilizadas para confirmar hallazgos
identificados por las herramientas automáticas y no se pretende un uso extensivo
de pruebas manuales. Las amenazas evaluadas en éste nivel de verificación son
virus y gusanos; éste nivel de verificación proporciona una cobertura parcial de la
verificación de la seguridad de la aplicación.

Nivel 2 – Verificación Manual: Éste nivel de verificación es típicamente el
apropiado para aquellas aplicaciones que manejan transacciones personales,
transacciones entre negocios también conocidas como business-to-business (B2B),
procesamiento de tarjetas de crédito o procesamiento de información
identificable de personas (PII por sus siglas en inglés). Éste nivel provee cierta
confianza en el uso de los controles de seguridad implementados así como en el
correcto funcionamiento de los mismos. El alcance de éste nivel es la evaluación
de cada uno de los componentes de la aplicación incluyendo el código
desarrollado por terceros o proveedores. Al igual que el nivel 1 se compone de
nivel 2A y 2B cuyos alcances son los mismos que para el nivel 1, es decir
herramientas automáticas para el primero y técnicas de verificación manuales
para el último. Las amenazas verificadas en éste nivel son virus, gusanos y ataques
básicos generados con herramientas de software libre.

Nivel 3 – Verificación del Diseño: Éste tipo de verificación es el apropiado para
aquellas aplicaciones que manejan transacciones B2B incluyendo aquellas que
procesan información del bienestar y salud de las personas o generan
transacciones críticas de los negocios. En éste nivel las amenazas verificadas son
virus, gusanos y atacantes con habilidades más desarrolladas para llevar acabo
ataques de seguridad complejos por medio de herramientas automáticas y scripts
personalizados. El alcance de éste nivel de verificación son el código nuevo o
33
modificado así como la evaluación de los componentes que proporcionan
seguridad a la aplicación y que han sido desarrollados por terceros; del mismo
modo, se asegura que los controles de seguridad se encuentren implementados
en todos los componentes de la aplicación y que estos estén funcionando de
manera adecuada.

Nivel 4 – Verificación Interna: Es el aplicado para aplicaciones críticas dedicadas a
proteger la vida y el bienestar de las personas, infraestructura crítica del negocio o
funciones de defensa. El nivel 4 asegura que los controles estén aplicados en
todos los componentes de la aplicación, que éstos se encuentren funcionando
correctamente y que las prácticas de desarrollo seguro de software se hayan
seguido a lo largo de todo el proceso. Las amenazas verificadas involucran desde
atacantes sofisticados con altas habilidades en el uso de herramientas
automáticas. El alcance de éste nivel es todo el código de la aplicación.
Adicionalmente, el estándar especifica puntos de validación que deben cubrirse por
cada nivel; el ASVS tiene definido 14 requerimientos de verificación de seguridad:

V1 – Requerimientos de Documentación de la Arquitectura de Seguridad

V2 – Requerimientos de Verificación de Autenticación

V3 – Requerimientos de Verificación de Administración de la Sesión

V4 – Requerimientos de Verificación de Control de Acceso

V5 – Requerimientos de Verificación de Validación de Entrada

V6 – Requerimientos de Verificación de Salida Encodificación/Escape

V7 – Requerimientos de Verificación de Criptografía

V8 - Requerimientos de Verificación de Manejo de Errores y Registro de Auditoria

V9 - Requerimientos de Verificación de Protección de Datos

V10 - Requerimientos de Verificación Seguridad en Comunicaciones

V11 - Requerimientos de Verificación de Seguridad en HTTP

V12 - Requerimientos de Verificación de Configuración de Seguridad
34

V13 - Requerimientos de Verificación de Búsqueda de Código Malicioso

V14 - Requerimientos de Verificación de Seguridad Interna
El proyecto ASVS también requiere estándares para hacer un reporte después de
ejecutar un análisis de seguridad de la aplicación; la siguiente figura muestra las secciones
generales que dicho reporte debería contener:
Figura 15 Contenido del reporte de la revisión de seguridad (OWASP, 2009)
1.1.10 OWASP Testing Guide
35
El Proyecto OWASP Testing Guide es un marco de desarrollo de pruebas a partir
del cual los profesionales puedan crear su propio programa de pruebas. Tiene como
principal objetivo hacer pruebas de penetración y pruebas integradas de seguridad dentro
del ciclo de desarrollo del software.
El proyecto define los pre-requisitos para realizar pruebas de aplicaciones web: el
alcance de las pruebas, los principios de una prueba exitosa, y las técnicas de prueba. Del
mismo modo presenta el Marco de Pruebas y explica las técnicas y tareas en relación a las
varias fases del ciclo de vida de desarrollo de software. Finalmente describe como realizar
pruebas para vulnerabilidades específicas a través de inspección de código y pruebas de
intrusión.
1.1.11 OWASP Software Assurance Maturity Model (SAMM)
El SAMM es un marco de referencia para ayudar a las organizaciones a
implementar una estrategia para tener seguridad en el software de acuerdo a los riesgos
específicos de la organización. La aplicación de SAMM ayudaría a las organizaciones a
(Chandra & Deleersnyder, 2012):

Evaluar las prácticas existentes de seguridad en el software.

Construir un programa de desarrollo de software seguro con iteraciones
bien definidas.

Demostrar mejoras concretas con base al programa definido.
El SAMM fue construido pensando en la flexibilidad de su implementación, ya que
pudiera ser implementado en empresas grandes, medianas o pequeñas; desde un área o
departamento, hasta toda la organización.
La base del modelo son las diferentes etapas del ciclo de desarrollo de software
con controles de seguridad añadidos a cada fase, de ésa forma, se puede construir el
36
programa para asegurar que el software se desarrolle de manera segura. SAMM define 4
funciones de negocio, y cada una tiene prácticas de seguridad definidas.
El SAMM cuenta con cuatro niveles de madurez definido por métricas y controles
implementados en la organización, donde 0 es el nivel más bajo y 3 el nivel más alto de
madurez para cada una de las prácticas de seguridad. La siguiente figura muestra las 12
prácticas de seguridad y sus respectivas funciones de negocio definidas por SAMM:
Figura 16 Modelo SAMM (Chandra & Deleersnyder, 2012)
Método
El tipo de investigación será Descriptiva (Hernández Sampieri, Fernández Collado,
& Baptista Lucio, 1991); ya que trataremos primero de describir e identificar cómo se
realizan los ataques de inyección de SQL; posteriormente describir los controles OWASP
que se pretenden implementar. Por último, y con base a las variables de investigación,
medir la efectividad de los controles OWASP para mitigar los ataques de inyección de SQL.
Por otro lado, el diseño del experimento será cuasi experimental (Hernández
Sampieri, Fernández Collado, & Baptista Lucio, 1991); lo anterior debido a que no nos será
posible tener una aplicación web con la misma arquitectura que otra, y tal vez las
tecnologías utilizadas para el desarrollo de las aplicaciones, así como la infraestructura en
37
la que se encuentran, será diferente. Del mismo modo, ninguna organización es igual a
otra aun estando dentro de una misma industria.
El diseño del experimento será de preprueba-postprueba y grupos intactos
(Hernández Sampieri, Fernández Collado, & Baptista Lucio, 1991). Éste diseño es el que
más se apega a la validación de las hipótesis planteadas; ya que nos permitirá hacer las
pruebas de penetración a las aplicaciones objetivo, y a evaluar el nivel de madurez de la
organización, antes de la aplicación de técnicas OWASP; obtener resultados, ejecutar de
nuevo las pruebas de penetración, evaluar de nuevo el nivel de madurez de la
organización, y de ésta manera comparar los resultados obtenidos antes y después de la
implementación de técnicas OWASP. El diseño nos permitirá aceptar o rechazar las
hipótesis planteadas en el Capítulo uno del presente estudio de caso.
Desde el punto de vista técnico, estaremos realizando las evaluaciones de las
vulnerabilidades de inyección de SQL con base al nivel cuatro de evaluación de (OWASP,
2009), cuyo alcance es todo el código que fue modificado o desarrollado para crear la
aplicación incluyendo librerías y servicios invocados; en términos de la aplicación web,
esto implica evaluar toda la aplicación.
Los requerimientos de verificación los estaremos acotando al nivel V5 (Input
Validation Verification Requirements) ya que es el que se apega a la verificación de
inyección de SQL; los puntos de verificación V5 correspondientes a un nivel de evaluación
cuatro se detallan en la siguiente tabla (OWASP, 2009):
Level 4
Level 3
Level 2B
Level 2A
Level 1B
Verification Requirement
Level 1A
Tabla 4 OWASP ASVS Requerimientos de Validación de Captura (V5) (OWASP, 2009)
38
V5.1
Verify that the runtime environment is
not susceptible to buffer overflows, or
that security controls prevent buffer
overflows.






V5.2
Verify that a positive validation pattern is
defined and applied to all input.






V5.3
Verify that all input validation failures
result in input rejection or input
sanitization.





V5.4
Verify that a character set, such as UTF-8,
is specified for all sources of input.




V5.5
Verify that all input validation is
performed on the server side.




V5.6
Verify that a single input validation
control is used by the application for
each type of data that is accepted.



V5.7
Verify that all input validation failures are
logged.



V5.8
Verify that all input data is canonicalized
for all downstream decoders or
interpreters prior to validation.


V5.9
Verify that all input validation controls
are not affected by any malicious code.

Utilizaremos diversas herramientas para automatizar la identificación y explotación
de la vulnerabilidad de inyección de SQL; dado el costo de las soluciones comerciales, nos
enfocaremos a utilizar soluciones de software libre como SQLiX, SQLmap, SQL Ninja, ZAP.
Por otro lado, evaluaremos las prácticas de desarrollo de software de la
organización con base al cuestionario de (Chandra & Deleersnyder, 2012), definiremos el
nivel de madurez descrito por SAMM y entregaremos las recomendaciones a la
organización. Se espera que la organización trabaje en esos puntos, para después de un
tiempo determinado con la organización objetivo, regresar y aplicar el mismo
cuestionario, verificando evidencias de la implementación de las recomendaciones, y
revaluar el nivel de madurez de (Chandra & Deleersnyder, 2012).
39
Capítulo III
CASOS DE ESTUDIO
“Los atacantes se adaptan constantemente, los defensores también necesitan
adaptarse de manera continua.” (Harkins, 2013)
40
Capítulo IV
CONCLUSIONES
“Los perdedores ignoran las tendencias. Los ganadores sobreviven por ser capaces
de predecir, prevenir, detectar y responder” (Harkins, 2013)
41
Resultados
Discusión
Conclusiones
Trabajo Futuro
42
Capítulo V
REFERENCIAS
43
Assumpcao Guimaraes, B., & Stampar, M. (2012). SQLmap. Recuperado el Abril de 2013,
de SQLmap: http://sqlmap.org/
Acunetix Ltd. (s.f.). Acunetix. Recuperado el Abril de 2013, de Acunetix:
http://www.acunetix.com/vulnerability-scanner/wvsbrochure.pdf
Carreon Mendoza, M. (2009). Esquema de Seguridad para el desarrollo de Aplicaciones
Web para CFE. Instituo Politécnico Nacional.
Chandra, P., & Deleersnyder, S. (2012). OWASP Software Assurance Maturity Model.
Creative Commons (CC) Attribution-Share Alike.
Clarke, J. (2012). SQL Injection Attacks and Defense, 2nd Edition. Syngress.
CWE/SANS. (September de 2011). 2011 CWE/SANS Top 25 Most Dangerous Software
Errors. Recuperado el May de 2013, de 2011 CWE/SANS Top 25 Most Dangerous
Software Errors: http://cwe.mitre.org/top25/
Dharam, R., & Shiva, S. (2012). Runtime Monitoring Technique to handle Tautology based
SQL Injection Attacks. International Journal of Cyber-Security and Digital
Forensics (IJCSDF) 1(3).
Diario Oficial de la Federación. (2010). DECRETO por el que se expide la Ley Federal de
Protección de Datos Personales en Posesión de los Particulares. Diario Oficial de la
Federación, 11-12.
EC-Council. (2011). Ethical Hacking and Countermeasures v6.1. EC-Council.
Harkins, M. (2013). Managing Risk and Information Security Protect to Enable. Apress
Media.
Harris, S. (2008). All in One CISSP Exam Guide. McGraw-Hill.
Hernández Sampieri, R., Fernández Collado, C., & Baptista Lucio, P. (1991). Metodología
de la investigación. Naucalpan de Juárez, Edo. de México: McGRAW - HILL
INTERAMERICANA DE MÉXICO, S.A. de C.V.
Hewlett-Packard. (2012). HP 2012 Cyber Risk Report.
Holm, H., Ekstedt, M., & Sommestad, T. (2013). Effort estimates on web application
vulnerability discovery. 46th Hawaii International Conference on System Sciences
(pág. 1). Hawaii: IEEE.
HP Web Inspect. (2013). Data Sheet. Recuperado el Abril de 2013, de HP:
http://h20195.www2.hp.com/V2/GetDocument.aspx?docname=4AA15363ENW&&cc=us&lc=en
icesurfer, & nico. (2012). SQL Ninja. Recuperado el Abril de 2013, de SQL Ninja:
http://sqlninja.sourceforge.net/
Levin, C. (2010). Opening Statement of Senator Carl Levin, Senate Armed Services
Committee Hearing on Nominations of Vice Admiral James A. Winnefeld and
Lieutenant General Keith B. Alexander.
McAfee Foundstone. (s.f.). McAfee. Recuperado el Abril de 2013, de WSDigger v1.0:
http://www.mcafee.com/mx/downloads/free-tools/wsdigger.aspx
McAfee Inc. (2012). Scanning Web Applications for Vulnerabilities. Recuperado el Abril
de 2013, de McAfee: http://www.mcafee.com/us/resources/solution-briefs/sb-scanweb-apps-vulnerabilities.pdf
Meucci, M., Keary, E., & Cuthbert, D. (2008). OWASP Testing Guide. Creative Commons
(CC) Attribution Share-Alike.
Murach, J., & Steelman, A. (2008). Java Servlets and JSP. Murach Editions.
44
OWASP. (2009). OWASP Application Security Verification Standard (ASVS). Creative
Commons (CC) Attribution Share-Alike.
OWASP. (2011). OWASP Enterprise Security API (ESAPI). Recuperado el Abril de 2013,
de OWASP Enterprise Security API (ESAPI):
https://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API
OWASP. (2011). OWASP Risk Rating Methology. Recuperado el Abril de 2013, de
OWASP Risk Rating Methology:
http://www.owasp.org/idex.php/OWASP_Risk_Rating_Methodology
OWASP. (2011). SQLiX Project. Recuperado el Abril de 2013, de OWASP:
https://www.owasp.org/index.php/Category:OWASP_SQLiX_Project
OWASP. (2013). OWASP ZAP Proxy. Recuperado el Abril de 2013, de OWASP ZAP
Proxy: http://code.google.com/p/zaproxy/
Parnell, B.-A. (2011). Cyber crime now bigger than the drugs trade. The Register.
Ponemon Institute. (2012). 2012 Cost of Cyber Crime Study:. Ponemon Institute LLC.
Puppy, R. F. (24 de Diciembre de 1998). Phrack. Recuperado el Abril de 2013, de NT Web
Technology Vulnerabilities:
http://www.phrack.com/issues.html?issue=54&id=8#article
Ramirez Lopez, J. (2009). Desarrollo de un Esquema de Análisis de Vulnerabilidades y
Pruebas de Penetración en Sistemas Operativos para una Organización de la
Administración Pública Federal. Insituto Politécnico Nacional.
Rodriguez Argueta, M. (2011). Análisis de la Seguridad en Sitios Web. Instituto Politécnico
Nacional.
Saenz Gonzalez, M. (2009). Diseño de un Laboratorio de Análisis de Vulnerabilidades y
Pruebas de Penetración en Redes de Cómputo. Instituto Politécnico Nacional.
SC Magazine. (2007). SC Magazine. Recuperado el Abril de 2013, de SC Magazine for IT
Security Professionals: http://www.scmagazine.com/reviews/section/107/
Scholt, T., Balzarotti, D., & Kirda, E. (2012). Have things changed now? An Empirical
Study on Input Validation Vulnerabilities in Web Applications.
SoftPile. (2008). AntiMalware Tools. Recuperado el Abril de 2013, de Softpile:
http://falcove-web-vulnerability-scanner.softpile.com/
Tatum, M. (Enero de 2013). What Is a Cyberattack? Recuperado el Marzo de 2013, de
Wise Geek: http://www.wisegeek.com/what-is-a-cyberattack.htm
The Open Source Vulnerability Database. (2012). The Open Source Vulnerability
Database. Recuperado el Marzo 2013 de 2013, de The Open Source Vulnerability
Database: http://www.osvdb.org
van der Stock, A. (2005). Una Guía para Construir Aplicaciones y Servicios Web Seguros.
Free Software Foundation.
Watson, C., & Coates, M. (2010). OWASP AppSensor. Cerative Common (CC) Share-A
Like.
Williams, J., & Wichers, D. (2013). OWASP Top Ten - 2013. Creative Commons (CC)
Attribution Share-Alike.
45