METODOLOGÍA DE PRUEBAS DE INYECCIÓN SQL PARA...

UNIVERSIDADPONTIFICIABOLIVARIANA–SECCIONALBUCARAMANGA

RevistaDigitalApuntesdeInvestigación|ISSN:2248-7875

Vol7–Septiembre2013Disponibleen:http://apuntesdeinvestigacion.bucaramanga.upbbga.edu.co/

METODOLOGÍA DE PRUEBAS DE INYECCIÓN SQL PARA ENTORNOS WEB

Gerson Geovanny Delgado Caballero1

Universidad Pontificia Bolivariana

Bucaramanga, Colombia

Resumen

La naturaleza de las aplicaciones Web, principalmente por el amplio mercado que ofrecen y por la capacidad de permitir su acceso a personas de todo el mundo las ha convertido en un flanco de ataque por parte de delincuentes cibernéticos, entre las técnicas encontradas para vulnerar los sitios Web se encuentra la inyección SQL la cual generalmente involucra las base de datos de un sitio Web, de ahí su nombre y se basa principalmente en explotar la relación que existe entre la aplicación y el servidor de base de datos. Esta relación es explotada para atacar la base de datos directamente a través de la aplicación, utilizando el servidor de base de datos para atacar otros sistemas en la organización. Con el presente artículo se busca proveer la suficiente información para que el lector pueda entender ésta técnica de ataque, además que logre dimensionar su alcance, causas y consecuencias. Este artículo no cubre la sintaxis SQL de base de base datos. Se supone que el lector tiene una sólida comprensión de estos temas. Este documento se centrará en definir qué es una inyección SQL, identificar una metodología de pruebas, identificar las técnicas de evasión y la forma de defenderse.

Palabras claves Inyección SQL, ataque, seguridad, aplicaciones Web.

1GersonGeovannyDelgadoCaballero,IngenierodeSoftwareyComunicaciones.EspecialistaenTelecomunicaciones.Email:[email protected]




Abstract

The nature of Web applications, mainly for the broad market offering and the ability to allow access to people around the world, has become a flank attack by cybercriminals, among the techniques found to infringe sites Web is SQL injection which usually involves a database of Web site, hence its name and is mainly based on exploiting the relationship between application server and database. This relationship is exploited to attack the database directly through the application using the database server to attack other systems within the organization. The present article seeks to provide sufficient information to enable the reader to understand this attack technique that achieves dimension also its scope, causes and consequences. This article does not cover the basic syntax of SQL database. It is assumed that the reader has a solid understanding of these issues. This paper will focus on defining who is a SQL injection, to identify a test methodology to identify the evasion techniques and how to defend themselves. Keywords: SQL injection, attack, security, Web applications.

1. Introducción Las aplicaciones en ambiente Web ofrecen a todo tipo de atacantes cibernéticos un mercado amplio y exquisito porque encuentran en ellas un punto de convergencia de un número muy importante de organizaciones y usuarios a nivel mundial más aún cuando éstas cada día se enriquecen cada vez con mejores contenidos como multimedia, música, información de todo tipo, entretenimiento, entre otras muchas ventajas, adicionalmente porque comercialmente tienen gran acogida por todo tipo de empresas independientemente de su objeto social. Lograr vulnerar estos sitios de encuentro común con el fin de obtener determinados beneficios es una tarea que cada vez mejoran más los atacantes cibernéticos, una técnica utilizada con gran frecuencia y con buenos resultados es la inyección SQL. Esta técnica permite que un atacante logre con esta vulnerabilidad de inyección SQL recuperar el contenido de la base de datos detrás de un firewall y de esta manera penetrar en la red interna, además puede causar la contaminación de toda la información sensible almacenada en la base de datos de una aplicación, incluida la información útil como nombres de usuario, contraseñas, direcciones, números de teléfono, datos de la tarjeta de crédito, entre otros. Entre los grandes problemas que enfrentan los administradores ante ataques de este tipo, es que es una de las vulnerabilidades más devastadoras para el impacto de un negocio ya que permite a los usuarios remotos acceder a información confidencial. La mayor importancia que se le da a este ataque radica en que el atacante aprovecha la sintaxis y las funcionalidades que le brinda el SQL2 en sí mismo, para la ejecución de dichas consultas, lo cual lo hace potencialmente peligroso ya que con ello puede realizar en el servidor

2SQL(StructuredQueryLanguage,LenguajeEstructuradodeConsultas).




de base de datos casi cualquier cosa que le sea permitida realizar. Así como existe el ataque existe la forma de protegerse de ellos y no se requiere implementar acciones extraordinarias que involucren una demora tan significativa en el desarrollo de las aplicaciones que prolongue de manera exagerada la puesta en producción del mismo, más aún cuando los propios lenguajes de programación y servidores Web ofrecen mecanismos para contrarrestar este tipo de ataques. Mediante la información proporcionada por este artículo el lector comprenderá la importancia de implementar las medidas de seguridad necesarias para minimizar el riesgo de sufrir ataques de tipo Inyección SQL y con ello crear aplicaciones más seguras y confiables. 2.¿QuéeslainyecciónSQL?La inyección SQL es un tipo de ataque en el que el atacante incluye declaraciones SQL malintencionados, a través de campos de entrada de cualquier tipo de software que precise del uso de base de datos, o una aplicación web que interactúe con una base de datos para funcionar, el cual se aprovecha de las vulnerabilidades que tienen dichas aplicaciones debido a que el desarrollador acepta que los datos del usuario se almacenen o depositen directamente en una sentencia SQL y no filtran correctamente los caracteres peligrosos.[1][2][3][4].

Tabla 1. Comandos DCL, DDL, DML,

Cláusulas y Operadores de Comparación Tomado de:

http://www.siclabs.com/descargas.php




La Inyección SQL recibe su nombre debido a que hace uso del lenguaje llamado SQL. Estas sentencias SQL pueden modificarla estructura de las bases de datos (usando instrucciones del lenguaje de definición de datos, o “DDL”) y manipular el contenido de las bases de datos (usando instrucciones del lenguaje de manipulación de datos, o “DML”). Dentro de los comandos básicos de SQL, se identifican cuatro grupos principales: Figura 1, Tabla 1 a), b), c), d), e). [5] [6] Los ataques de inyección SQL son ayudados la mayoría de las veces por los mensajes de error detallados y datos sin filtrar devueltos por la aplicación que se muestran en la interfaz del usuario. Con cada error, ayuda al atacante obtener información sobre la base de datos y a crear y a refinar el ataque. Algunos administradores desactivan estos errores (SHOW_ERRORS y SHOW_WARNINGS) para que no se muestren posibles errores provocados en el intérprete




SQL, esto hace que la explotación de un posible ataque de inyección SQL sea más difícil pero no imposible, el atacante puede robar datos haciendo una serie de consultas de Verdadero/Falso (Lógica Booleana) a través de sentencias SQL. En la Tabla 6 se puede observar una lista de caracteres muy útiles para la inyección SQL. Estos símbolos son usados es SQL993. [7][8][9]

Tabla 2. Caracteres para Inyección SQL Tomado de:

http://www.siclabs.com/descargas.php

Aunque la tarea inicial para el atacante es identificar los sitios que poseen este tipo de vulnerabilidad. Casi todas las bases de datos y lenguajes de programación son potencialmente vulnerables: MS SQL Server, Oracle, MySQL, PostgreSQL DB2, MS Access, Sybase, Informix, etc, porque se trata de un problema de validación de entrada que tiene que ser considerado y programado por el desarrollador de aplicaciones web. [9] 3. METODOLOGÍA DE PRUEBAS PARA LA INYECCIÓN SQL

3LaversiónSQL3(TambiénreferidaporalgunoscomoSQL99).http://en.wikipedia.org/wiki/SQL:1999




Pasos a seguir: 3.1 Entender el Funcionamiento de la Aplicación Web.

Aunque las diferentes aplicaciones se comportan de diferentes maneras, el fundamento es el mismo, debido a que todos los entornos son basados en Web. Hay que observar cómo el navegador envía las peticiones al servidor Web. Las peticiones que se envían al servidor Web pueden ser de dos posibles formas: Visibles (Método GET) u ocultos (Método POST). Como se observa en la figura 2. El usuario realiza a través del navegador la petición de una página Web. El servidor Web identifica la solicitud que para este caso, es una página dinámica, por lo tanto esta debe ser interpretada por el motor de PHP el cual ejecuta el código. Dentro del código se obtiene el valor de las variables enviadas por el usuario, con base en ello procede a conectarse al servidor de base de datos para realizar la respectiva consulta. Finalmente el resultado de la ejecución del código PHP, es tomado por el servidor Web para ser enviado al navegador del usuario como respuesta a su solicitud. Algunas veces, la respuesta incluirá un error de SQL de la base de datos, esto ayuda a obtener información importante, sin embargo, otras veces hay que estar concentrado y detecta diferencias sutiles. [6][12][13] 3.2 Validar Entradas y Recopilar Información.




La Inyección SQL se puede presentar en cualquier parte de la aplicación Web, por esta razón se identifican todas las entradas de datos en la aplicación web, qué tipo de solicitud podría provocar anomalías y detectar las anomalías en la respuesta del servidor. Se realizan las validaciones para de esta manera encontrar una entrada vulnerable en la aplicación Web. Una vez detectadas las anomalías el siguiente paso es reunir la mayor información posible acerca de la aplicación Web a través de lo siguiente: Los mensajes de error: Estos mensajes de error generan información valiosa. Diversas bases de datos permiten y requieren diferentes sintaxis SQL. Definir el tipo de motor de base de datos es fundamental para las siguientes etapas. La mayoría de los mensajes de error indican con qué base de datos están trabajando. Al identificar el sistema operativo y el servidor web a veces es más fácil deducir la posible base de datos. Entender la consulta: La consulta, puede ser un "SELECT", "UPDATE", "INSERT" o algo más complejo. Es importante determinar lo que el formulario o la página está tratando de hacer con la entrada para determinar en qué parte modificar la consulta. [6][9][11][12][13] 3.3 Determinar el Nivel de Privilegios de Usuario, el Nombre y la Versión de la Base de Datos. Con el uso de caracteres específicos (@@version) puede saber con certeza la versión de la base de datos. Pero para esto es fundamental identificar el número de columnas de la tabla o campos seleccionados en la consulta. Esto se logra a través de la utilización de la clausula ORDER BY. La cual le permite ordenar los resultados en función de los campos que hayan sido seleccionados en la consulta. La consulta anterior (Ejemplo 1) ordena los campos por apellido. Otra alternativa para indicar el nombre del campo es utilizando su posición. Con esta consulta (Ejemplo 2) se podrá ir ordenando por el primer campo, luego por el segundo y así de forma incremental hasta generar un error de este tipo: La posición 3 no existe porque solo se




seleccionaron 2 campos (nombre y apellido), por esta razón genera este tipo de errores. Cuando esto suceda se sabrá cuantos campos se seleccionaron en la consulta sin necesidad de mirar el código fuente o la estructura de la consulta. Identificado el número de campos seleccionados en la consulta, se debe determinar cuál de todos esos campos se muestran en la aplicación Web. No todos los campos seleccionados se suelen mostrar en la página Web de respuesta, algunos son utilizados internamente por la aplicación. Determinar qué campos son visibles servirá para mostrar a través de ellos la información que se quiere de la base de datos (el tipo y la versión). Para esto es necesaria la utilización de la cláusula UNION, la cual indica que se debe unir el resultado de la consulta anterior con los resultados de la consulta posterior. Para que esto sea posible las consultas deben tener el mismo número de campos, de lo contrario se generaría un error; por esta razón, es fundamental determinar el número de campos seleccionados en las consultas. Una vez identificados los campos seleccionados, estos permiten realizar las respectivas consultas SQL con los caracteres específicos. [user(), versión(), database()]. La unión de estas dos consultas (Ejemplo 3) muestra como resultado los datos de los usuarios con id 1 y 2. SQL integra varias funciones que funcionan en la mayoría de las bases de datos:

• user or current_user • session_user • system_user • ' and 1 in (select user )

Estas funciones devuelven el nombre de usuario dentro de un mensaje de error. Para tener el mayor éxito en la inyección SQL se requiere altos niveles de privilegios de usuario. Esto nos indica lo que puede o no puede hacer el usuario, que al final servirá para ahorrar tiempo. [6][8][9][13] 3.4 Realizar el Ataque. Conociendo la información básica de la base de datos, la estructura de la consulta y los privilegios, se procede a iniciar el ataque. Descubrir la estructura de la base de datos. MySQL guarda los metadatos de las bases de datos en una base de datos llamada INFORMATION_SCHEMA (Figura 3), la cual es la base de datos de información, donde se almacena información sobre todas las otras bases de datos que mantiene el servidor MySQL. Dentro de INFORMATION_SCHEMA hay varias tablas de sólo lectura. Aunque se puede seleccionar INFORMATION_SCHEMA como base de datos por defecto con el comando USE, sólo se puede leer el contenido de las tablas, no efectuar operaciones INSERT, UPDATE o DELETE. [6][9] [11][12]




Nos enfocaremos en las siguientes tablas:

• SCHEMATA: Bases de datos. • TABLES: Tablas en las bases de datos. • COLUMNS: Columnas en las tablas.

Enumeración de la base de datos. En MySQL un esquema es una base de datos, por lo tanto la tabla SCHEMATA (Figura 4), proporciona información acerca de las bases de datos. En el campo SCHEMA_NAME se encuentran los nombres de todas las base de datos.[6][9]




Enumeración de las tablas del sistema. En MySQL la tabla TABLES (Figura 5) proporciona información acerca de las tablas en las bases de datos. El campo TABLE_SCHEMA contiene información de los nombres de la base de datos y el campo TABLE_NAME contiene el nombre de las tablas. [6][9][11][13] Enumeración de las columnas de las tablas de diferentes bases de datos: Algunos servidores tienen varias bases de datos. Se pueden extraer al interrogar a las tablas del sistema de información de metadatos sobre las bases de datos. En MySQL la tabla COLUMNS (Figura 6) proporciona información acerca de las columnas en las tablas. En el campo COLUMN_NAME se encuentran los nombres de las columnas. Las tablas TABLES y COLUMNS, contienen 3 columnas que son compartidas:

• TABLE_SCHEMA: Contiene los metadatos de las bases de datos. • TABLE_NAME: Contiene el nombre de las tablas. • COLUMN_NAME: Contiene el nombre de las columnas de la tabla en cada base de

datos. [13][15]




3.5 Extracción de Datos. La extracción de los datos es fácil una vez que la base de datos ha sido enumerada y las consultas se han entendido. Estos datos se utilizan para extraer la información o los datos.

• Extraer el nombre de usuario y contraseña de una tabla definida por el usuario. • Extraer los hash de las contraseñas de base de datos. • Transferir la estructura de la base de datos y los datos a través de una conexión inversa

a un servidor SQL Server local. • Crear una estructura de base de datos idéntica. Mediante la transferencia de los

metadatos de la base de datos se puede crear la estructura de base de datos en el sistema local.

• Transferir la base de datos. Creada la estructura, los datos pueden transferirse fácilmente. Este método permite al atacante recuperar el contenido de una tabla incluso si la aplicación está diseñada para ocultar mensajes de error o resultados no válidos de la consulta. [6][9][13]

3.6 Interacción con el Sistema Operativo. Dependiendo del tipo de base de datos y los privilegios que se obtengan es posible interactuar directamente con el sistema operativo subyacente. Dos formas de interactuar con el sistema operativo:

• Lectura y escritura de archivos del sistema desde disco. • Ejecución directa de comandos

En ambos casos se verá restringido por los privilegios y permisos del usuario con el que se ejecuta el motor de base de datos. No siempre es posible evadir al sistema operativo para la ejecución directa de comandos a través de la inyección SQL. En la mayoría de base de datos, la ruta de acceso al sistema operativo no es directa. Se debe realizar la búsqueda de contraseñas y en algunos casos reemplazar archivos de configuración para lograr acceder indirectamente. Otra forma de ejecutar comandos es a través de la automatización de Scripts para ActiveX. [9][13] 3.7 Ampliar la influencia. En esta etapa final el atacante puede ampliar su influencia saltando a otras aplicaciones o servidores de base de datos. Vincula estos servidores remotos para comunicarse de forma transparente con ellos y de esta manera realizar consultas distribuidas e incluso controlar estos servidores de base de datos de forma remota y utilizar esa capacidad para acceder a la red interna. También es posible subir archivos a través de una conexión inversa y de una inyección SQL y ejecutar de forma remota procedimientos almacenados, debido que algunos servidores están configurados únicamente para permitir la ejecución remota de dichos procedimientos.[9]




4. APLICACIÓN DE LA METODDOLOGÍA. 4.1 Funcionamiento de la Aplicación Web: La aplicación web de ejemplo permite que mediante un formulario de inicio de sesión le pida al usuario su identificador (ID), para que posterior a su validación le muestre al usuario la información o el acceso que la aplicación Web tiene disponible para él. (Figura 7) Al observar la URL de la aplicación se identifican los parámetros que van después del signo de interrogación (?) separados entre si por el signo et (&), estos parámetros indican exactamente el número de ID a consultar en la página Web (Figura 8). Se identifica que el método utilizado es el método GET donde claramente se observa la variable y su valor en la URL 01020304. 4.2 Validar Entradas y Recopilar Información: Los mensajes de error. Con el mensaje de error suministrado se puede determinar que la base de datos utilizada en la aplicación es MySQL (Figura 9). Entender la consulta. Identificado en el paso anterior que se utiliza el método GET, se puede deducir en las lineas del codigo PHP (Ejemplo 4) que los valores enviados no tienen ninguna validación. Esta es una posible forma como se obtienen los valores enviados por el usuario:




Luego se puede deducir que más adelante se concatena el valor de la variable $id para formar la consulta SQL (Ejemplo 5). Si por ejemplo el $id fuera 1 la consulta quedaría de la siguiente manera (Ejemplo 6): La orden SELECT sirve para consultar registros de la base de datos. En el ejemplo 6 se estarían consultando todos los registros de la tabla users cuyo valor de la columna id sea igual a 1. 4.3 Determinar el Nivel de Privilegios de Usuario, el Nombre y la Versión de la Base de Datos.

• Obteniendo el número de campos seleccionados. Figura 10 a), b), c).




• Identificando los campos que son visibles. Figura 11 a), b).




• Obteniendo el nombre de la base de datos, el nombre de usuario y la versión de la base

de datos. Figura 12 a), b).




4.4 Realizar el Ataque.

• Descubriendo la estructura de la base de datos. Figura 13. • Enumeración de la base de datos. Figura 13.

• Enumeración de las tablas del sistema. Figura 14.




• Enumeración de las columnas de las tablas de diferentes bases de datos. Figura 15.

4.5 Extracción de Datos. Información obtenida de la enumeración.

• Base de datos: dvwa • Tabla: users • Columnas: user, password

Extracción de la información o los datos:

• Nombre de usuario y contraseña. Figura 16. • Hash de las contraseñas. Figura 16.




• Crackear las contraseñas encriptadas con MD5.




• Contraseña crackeada: password 4.6 Interacción con el Sistema.

• Lectura y escritura de archivos del sistema. Figura 19.




4.7 Ampliar la Influencia.

• Subir archivos a través de una conexión inversa o de una inyección SQL. Figura 20.




5. TÉCNICAS DE EVASIÓN Y DEFENSA CONTRA INYECCIÓN SQL. Algunas son del tipo predictivo que permiten detectar y bloquear los ataques, incluso en tiempo real y otros son del tipo preventivos. Actualmente existen varias formas para evadir y defenderse de los ataques de inyección SQL. Es importante recordar que las soluciones analizadas son complementarias, en su conjunto las técnicas que se plantean ayudan a conseguir una arquitectura de seguridad multicapa. [18] 5.1 Defensas a Nivel de Código. Es la defensa más eficaz contra los ataques de inyección SQL. [18]

• Conexiones con mínimos privilegios. • Validar los datos especificados por el usuario mediante comprobaciones de tipo,

longitud, formato e intervalo. • No hacer suposiciones sobre el tamaño, tipo de contenido de los datos que recibirá la

aplicación. • Comprobar el tamaño y el tipo de los datos especificados y aplique los limites

adecuados. • Comprobar el contenido de las variables de cadena y aceptar únicamente los valores

esperados. • Rechazar las especificaciones que contengan datos binarios, secuencias de escape y

caracteres de comentario. • Para los entornos de varios niveles, todos los datos deben validarse antes de que se

admitan en la zona de confianza. Los datos que no superen el proceso de validación deben rechazarse, y debe devolverse un error al nivel anterior.




• Implementar varias capas de validación, es decir, validar los datos especificados por el usuario en la interfaz de usuario y, después, en todos los puntos posteriores que atraviesen un límite de confianza.

• No concatene los datos especificados por el usuario que no se hayan validado. • Rechazar los datos que contengan diversidad de caracteres. [17] [20]

5.2 Defensas a Nivel de Base de Datos. Nunca confié en su aplicación Web, las aplicaciones cambian a través del tiempo y las vulnerabilidades inesperadas pueden aparecer, por es necesario el realizar el endurecimiento “Hardening” al servidor de base de datos.

• En lo posible separar la base de datos del servidor de aplicaciones. • Deshabilitar o Restringir el acceso remoto. • Deshabilitar el uso de permisos que puedan leer ficheros del sistema operativo desde la

base de datos. • Cambiar el nombre de usuario y la contraseña del usuario root. • Eliminar la base de datos por defecto “Test” que se distribuye con el servicio. • Eliminar las cuentas anónimas y obsoletas. • Utilizar privilegios mínimos del sistema. • Utilizar privilegios mínimos de la base de datos. • Configurar los log. • Cambiar el directorio raíz a una partición distinta al sistema operativo. • Eliminar el historial de la línea de comandos del usuario de la base de datos. • Aplicar actualizaciones de seguridad del sistema operativo y del motor de base de datos.

5.3 Defensas a Nivel de Plataforma. Una defensa a nivel de plataforma es cualquier mejora o cambio de configuración en tiempo real que se puede hacer para aumentar la seguridad global de la aplicación. [12] Aunque la protección en tiempo real proporciona muchos beneficios, es necesario considerar algunos de los costos que pueden estar implicados, pero también existen soluciones de software gratuitas que están disponibles para su descarga en internet. La solución mas conocida en la seguridad de las aplicaciones Web es el uso de un firewall de aplicación Web (WAF). Un WAF es un dispositivo de red o solución basada en software que agrega características de seguridad para una aplicación Web. Uno de los WAF mas utilizados y de código abierto es el ModSecurity, el cual se implementa como un modulo del servidor web Apache. ModSecurity puede proteger prácticamente cualquier aplicación Web, incluso las aplicaciones Web basadas en ASP y ASP.NET. [12][24] Puede utilizar ModSecurity para la prevención de ataques, la vigilancia, la detección de intrusos y en general el endurecimiento de las aplicaciones. [12][24] La fortaleza de ModSecurity es la combinación de directivas de configuración y un lenguaje de programación simple aplicado a las peticiones y respuesta HTTP. El pronóstico generalmente es una acción específica, como permitir el paso de la solicitud, registrar la solicitud o el bloqueo de la misma. GreenSQL es otro firewall de aplicaciones que brinda seguridad a las bases de datos. Soporta MySQL y PostgreSQL en su versión Express y en su versión comercial soporta Microsoft SQL Server. GreenSQL es un firewall de base de datos de código abierto utilizado para la proteger las bases de datos de los ataques de Inyección SQL. Opera como un proxy entre el servidor de base de datos (MySQL, PostgreSQL o Microsoft SQL Server) y la aplicación




Web. Su lógica se basa en la evaluación de los comandos SQL utilizando una matriz de calificación de riesgos, así como el bloqueo de comandos conocidos utilizados en la administración de las bases de datos (DROP, CREATE, etc.) GreenSQL puede ser utilizado para operar en los siguientes modos: [23]

• Modo simulación. (Modo IDS). • Bloqueo de comandos sospechosos. (Modo IPS) • Modo Aprendizaje. • Protección activa para consultas desconocidas.

La peticiones que son enviadas a la aplicación Web, se envían a través del puerto de escucha de GreenSQL (Puerto 3305), el cual las analiza y las reenvía al servidor de base de datos. [23] Se recomienda para su configuración inicial habilitar en modo aprendizaje con el objetivo de no generar ningún impacto en las consultas que son enviadas o generadas para la aplicación Web. En este modo todas las consultas se añaden automáticamente a una lista blanca (Whitelist) o lista permitida. Una vez determinadas las consultas que son importantes para la aplicación Web se puede proceder a cambiar al modo de protección activa. Ofrece una intrerfaz gráfica de gestión compatible con los navegadores más comunes, con un conjunto de opciones para su configuración. [23]




6. Conclusiones El eslabón más débil en una aplicación Web para que permita ataques de inyección SQL es la poca o ninguna validación de las variables de entrada. Los desarrolladores deben reconocer que la seguridad es un componente fundamental de cualquier producto de software y deben incluir buenas prácticas de programación en el software que se esté desarrollando. Construir la seguridad en un producto es mucho más fácil y mucho más rentable que cualquier intento posterior a la eliminación o mitigación de los defectos descubiertos por los intrusos. Es una de las vulnerabilidades que genera mayor impacto porque permite el acceso a la información sensible o confidencial de una organización o entidad. Los diferentes motores de bases de datos y los mismos lenguajes de programación implementan técnicas para contrarrestar este tipo de ataques pero la principal responsabilidad se encuentra en el desarrollador quien debe validar correctamente las entradas de datos. 7. Agradecimientos Agradecimientos para Dios por las capacidades intelectuales otorgadas, a mis padres por su constante e incondicional apoyo y a todos los autores de las diversas referencias bibliográficas consultadas.

8. Biografía Gerson Delgado nació en Piedecuesta – Santander, Especialista en Telecomunicaciones de la Universidad Industrial de Santander – Bucaramanga, Colombia en 2011. Ingeniero de Software y Comunicaciones de la Universidad de Santander – Bucaramanga Colombia en 2004. Amplio interés por la seguridad informática, la investigación y las nuevas tecnologías. Actualmente se desempeña como profesional de seguridad informática de una prestigiosa entidad Financiera.




9. Referencias [1]. SQL Injection (2010). [Online]. Disponible en: http://www.owasp.org/index.php/SQL_Injection [2]. Sagar, Joshi (2005). SQL Injection Attack and Defense. [Online]. Disponible en: http://www.securitydocs.com/library/3587 [3]. Kenkeiras (2010). SQL Injection. [Online]. Disponible en: http://talleres.hackxcrack.es/ [4]. Litchfield, David (2005). Data-mining with SQL Injection and Inference. [Online]. Disponible en: http://www.databasesecurity.com/webapps/sqlinference.pdf [5]. Anley, Chris (2002). Advanced SQL Injection In SQL Server Applications. [Online]. Disponible en: http://www.ngssoftware.com/Libraries/Documents/Advanced_SQL_Injection_in_SQL_Server_Applications.sflb.ashx [6]. Racciatti, Hernán (2005). SQL Injection. “Tres años después… Detección y Evasión”. [Online]. Disponible en: http://www.sicinformatica.com.ar/media/SQL%20Injection%20-%20Deteccion%20y%20Evasion.zip [7]. Blindfolded SQL Injection (2009). [Online]. Disponible en: http://www.imperva.com/docs/Blindfolded_SQL_Injection.pdf [8]. Ka0x (2008). Técnicas de inyección en MySQL. [Online]. Disponible en: http://www.exploit-db.com/wpcontent/themes/exploit/docs/216.pdf [9]. Chapela, Víctor (2005). Advanced SQL Injection. [Online]. Disponible en: http://www.owasp.org/images/7/74/Advanced_SQL_Injection.ppt [10]. OWASP (2010). Open Web Application Security Project. [Online]. Disponible en: http://www.owasp.org/index.php/Main_Page [11]. Martorella, Christian (2008). Principales vulnerabilidades en aplicaciones Web. [Online]. Disponible en: http://www.edgesecurity.com/docs/Edge-Security_Rediris2008.pdf [12]. Clarke, Justin (2009). SQL Injection Attacks and Defense. Ed. Syngress Publishing, Inc. [13]. McCray, Joe. Advanced SQL Injection. [Online]. Disponible en: http://www.toorcon.org/tcx/9_McCray.pdf [14]. Warneck, Brad (2007). Defeating SQL Injection IDS Evasion. [Online]. Disponible en: http://www.giac.org/certified_professionals/practicals/gcia/1231.php [15]. Inyección SQL en Aplicaciones Web (I) (2007). [Online]. Disponible en: http://informaticapractica.net/solocodigo/index.php/2007/09/05/inyeccion-sql-enaplicaciones-web-i/




[16]. Anley, Chris (2002). (more) Advanced SQL Injection. [Online]. Disponible en: http://www.ngssoftware.com/Libraries/Documents/more_Advanced_SQL_Injection.sflb.ashx [17]. Cerullo, Fabio (2010). OWASP Top 10 – 2010, Los diez riesgos más importantes en aplicaciones web. [Online]. Disponible en: http://www.owasp.org/images/1/19/Owasp_top10_spanish.pdf [18]. Nystrom, Martin (2007). SQL Injection Defenses. Ed. O’reilly Media. [19]. Fisk, Harrison (2004). Prepared Statements. [Online]. Disponible en: http://dev.mysql.com/techresources/articles/4.1/preparedstatements.html [20]. SQL Injection Prevention Cheat Sheet (2010). [Online]. Disponible en: http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet [21]. Ramos, Alejandro (2010). Fortificación de MySQL – 1/3. [Online]. Disponible en: http://www.securitybydefault.com/search?q=sql+1 [22]. OWASP Testing Guide V3.0 (2008). [Online]. Disponible en: http://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf [23]. GreenSQL. [Online]. Disponible en: http://www.greensql.net/about [24]. Modsecurity. [Online]. Disponible en: http://www.modsecurity.org/

METODOLOGÍA DE PRUEBAS DE INYECCIÓN SQL PARA...

Documents

Transcript of METODOLOGÍA DE PRUEBAS DE INYECCIÓN SQL PARA...