INYECCION SQL

INYECCION SQL

RUBY YADIRA MORENO RAMIREZ SEMINARIO DE GRADO FUNDACION UNIVERSITARIA SAN MATEO

La inyección SQL consiste en la modificación del comportamiento de nuestras consultas mediante la introducción de parámetros no deseados en los campos a los que tiene acceso el usuario

I.  Introducción

El Lenguaje de Consulta Estructurado (Structured Query Language), cariñosamente conocido (por nosotros) con la nomenclatura de SQL, es un lenguaje declarativo de acceso a bases de datos relacionales que permite especificar diversos tipos de operaciones sobre las mismas. Concentra características del álgebra y el cálculo relacional permitiendo lanzar consultas con el fin de recuperar información de interés de un "banco de registros", de una forma sencilla y poderosa. Forma parte de los lenguajes de Cuarta Generación (4GL).

Sus orígenes dan a conocer que en 1970, Codd, propone el modelo relacional y asociado a este un sublenguaje de acceso a los datos basado en el cálculo de predicados. Apoyándose en estas ideas, los laboratorios de IBM definen el lenguaje SEQUEL (Structured English QUEry Language) que más tarde sería ampliamente implementado por el SGBD (Sistema de Gestión de Base de Datos) experimental System R, desarrollado en 1977 también por IBM. Sin embargo, fue Oracle quien lo introdujo por primera vez en 1979 en un programa comercial.

En la actualidad el SQL es el estándar de facto de la inmensa mayoría de los SGBD comerciales. Y, aunque la diversidad de añadidos particulares que incluyen las distintas implementaciones comerciales del lenguaje es amplia, el soporte al estándar SQL-92 es general y muy extenso.

Así mismo, el ANSI (Instituto Nacional Estadounidense de Estándares) SQL sufrió varias revisiones y agregados a lo largo del tiempo, por ejemplo, en una de sus últimas observaciones estudiadas, se permitió incluir:

Características del XML (Lenguaje de Marcas Extendidos), columnas auto numéricas, cambios y avances en ciertas funciones, etcétera.

Suelen utilizarse métodos de engaños para obtener contraseñas o información útil. Pueden emplearse páginas web falsas, programas engañosos o incluso simplemente chatear con una persona ignorante del tema. Increíblemente, la mayoría de las personas son lo suficientemente ilusas como para dar contraseñas a un extraño.

 II. ATAQUES

Una de las partes más vulnerables en una página web es la información contenida en la base de datos, y por lo tanto es una de las partes a las que hemos de prestar más atención.

Para interactuar con la base de datos utilizamos una serie de queries que nos permiten insertar, consultar o borrar datos, y que por lo tanto debemos saber en todo momento qué está haciendo cara una de las queries.

El problema viene cuando estas queries se construyen a través de valores obtenidos de formularios.

Un ejemplo de SQL injection es el siguiente:

Supongamos que tenemos un formulario de autenticación en el que se pide un login y un password.

La consulta de los valores desde un proceso php queda de la siguiente forma:

SELECT * FROM `tabla` WHERE `user`

= '$_POST[usuario]' && `pass` = '$_POST[pass]'

Si los valores introducidos en los campos del formulario son: 

Login: user

Password: ‘|| 1 = ‘1

La query quedará de la siguiente forma:

SELECT * FROM `tabla` WHERE `user` = 'user' && `pass` = '' || 1 = '1'

Con lo cual el usuario será siempre autenticado positivamente.

Para evitarlo debemos implementar una serie de funciones php que filtren las entradas de los usuarios, una posible función sería la siguiente:

<?

Function secureSQL( strVar )  

dim banned, final, I banned = array("select", "drop", ";", "--", "insert","delete", "xp_")

for i = 0 to unbound(banned)

strVar = replace(strVar, banned(i), "")  

next  
final = replace(strVar, "'", "''")  

SecureSQL = final

End Function

?>

Mediante esta función filtramos todos los caracteres extraños de la sentencia, evitando así un caso como el anteriormente comentado.

Una función que también nos será de gran utilidad para evitar éste tipo de ataques es la función addslashes.

III.  CONTRAMEDIDAS

Los riesgos de SQL Injection pueden superarse relativamente fácil con cambios de programación simples, que sin embargo requieren considerable disciplina de los programadores para aplicar los métodos siguientes para cada procedimiento y función accesibles de la red.

Variables de alcance: La más poderosa protección contra el SQL Injection es utilizar solamente variables de alcance para imposibilitar la concatenación de instrucciones SQL donde puedan aplicarse variables en las instrucciones anexadas.

Validación de la entrada: es necesaria una validación fuerte en lado de servidor para entrada de usuario, validación de datos filtrar la entrada del usuario de caracteres SQL, verificar tanto el tamaño como el tipo de los datos y sintaxis de las entradas de usuario. Este punto se aplica a muchos ataques similares, en particular lo reafirmaremos para los próximos ataques analizados.

Mensajes de error: Los mensajes de error a menudo revelan demasiada información que puede ser útil al atacante (nombres de tablas, campos, vistas); por lo tanto no se deberá exponer al usuario final los mensajes de error devueltos por el gestor de la base de datos.

Los mensajes de errores de la base de datos deberían ser notificados solamente a los administradores de la aplicación.

IV.  MANIPULACION DE PARAMETROS

Es un conjunto de técnicas que atacan la lògica de negocio de la aplicación, tomando ventaja del uso de campos ocultos o fijos para la transferencia de información sensible entre browser y servidor. En particular, tags ocultos en un form, cookies o parámetros anexados a la URL son fácilmente modificables por un atacante.

Vamos a analizar dos tipos en particular: manipulación de campos ocultos y manipulación de URL

V.  MANIPULACION DE CAMPOS OCULTOS

Cualquiera de los valores que se almacenan en los campos de un form pueden ser manipulados por un atacante. En particular los campos ocultos son usualmente atractivos para su manipulación ya que muchos desarrolladores los utilizan para información confidencial de estatus de algún objeto sobre el que se está trabajando.

La manipulación de estos campos es tan simple como salvar la página, editar el valor de estos campos en su código HTML y recargarla en el browser.

V. CONCLUSIONES

Los Ataques por SQL Injection son realmente peligrosos, no únicamente por la capacidad de daño que conllevan, sino porque son vulnerabilidades que muchos programadores no corrigen a tiempo (ni se preocupan, a posteriori, de hacerlo). Es decir, que todo ello se basa sobre los pilares del tan renombrado y cierto (como aterrador) Factor Humano. Por ello, espero que esta Nota, más que para propiciar el uso de este tipo de embates, sirva para prevenirlos de una posible y, tal vez, futura "Guerra Digital".

La Solución al SQL Injection reside en una consistente y absoluta revisión y/o confrontación profesionalmente idónea de todos los parámetros y cuestiones dirigidas a las Bases de Datos y la Programación/Diseño con respecto a su hábitat. Por ende, es preciso estar al día en materia de Seguridad Informática para controlar las Nuevas Técnicas de Inyecciones SQL que surgen continuamente (al paso del tiempo); indudablemente, más perfeccionadas y difíciles de combatir (nótese que no incluí la mera probabilidad de un imposible).

.