Está en la página 1de 6

PREVENCIN DE ATAQUE SQL INJECTION

Fabin Revelo
Estudiante de la Universidad Tcnica de Ambato
Facultad de Ingeniera en Sistemas Electrnica e
Industrial
Ambato Ecuador
faby89.science@gmail.com

RESUMEN
En el presente trabajo, se ha realizado la
configuracin para corregir el ataque que se puede
llevar a cabo a travs de sql injection (sqlmap), a
una base de datos. Se identifican los parmetros
que se deben tomar en cuenta, para realizar la
proteccin contra dicha infiltracin; de esta forma
se realiza un cdigo en lenguaje php, verificando
que nuestra seguridad sea robusta. De esta forma se
identifican los puntos crticos y los mecanismos
que debemos llevar a cabo para que nuestro sistema
informtico (pginas web), sea seguro, evitando as
la prdida o degradacin de valiosa informacin
personal o empresarial.
ABSTRACT
In this paper, the configuration has been done to
correct the attack can be carried out through sql
injection (sqlmap) to a database. The parameters to
be taken into account, for protection against such
infiltration was identified; thus a code in php
language is done by verifying that our security is
robust. Thus the critical points and the mechanisms
that we perform for our computer system (web
pages), safe, avoiding the loss or degradation of
valuable personal and business information are
identified.
PALABRAS CLAVE
phyton, php, sql injection, sqlmap, attack.

Byron Palacios
Estudiante de la Universidad Tcnica de Ambato
Facultad de Ingeniera en Sistemas Electrnica e
Industrial
Ambato Ecuador
byronpalacioss@outlook.es

INTRODUCCIN
Se dice que existe o se produjo una inyeccin
SQL cuando, de alguna manera, se inserta o
"inyecta" cdigo SQL invasor dentro del cdigo
SQL programado, a fin de alterar el funcionamiento
normal del programa y lograr as que se ejecute la
porcin de cdigo "invasor" incrustado, en la base
de datos.
Este tipo de intrusin normalmente es de carcter
malicioso, daino o espa, por tanto es un problema
de seguridad informtica, y debe ser tomado en
cuenta por el programador de la aplicacin para
poder prevenirlo. Un programa elaborado con
descuido, displicencia o con ignorancia del
problema, podr resultar ser vulnerable, y la
seguridad del sistema (base de datos) podr quedar
eventualmente comprometida.
La intrusin ocurre durante la ejecucin del
programa vulnerable, ya sea, en computadores de
escritorio o bien en sitios Web, en ste ltimo caso
obviamente ejecutndose en el servidor que los
aloja.[2]
La
vulnerabilidad
se
puede
producir
automticamente
cuando
un programa "arma
descuidadamente" una sentencia SQL en tiempo de
ejecucin, o bien durante la fase de desarrollo,

cuando el programador explicita la sentencia SQL a


ejecutar en forma desprotegida. En cualquier caso,
siempre que el programador necesite y haga uso de
parmetros a ingresar por parte del usuario, a
efectos de consultar una base de datos; ya que,
justamente, dentro de los parmetros es donde se
puede incorporar el cdigo SQL intruso.

Si entra user=pe'dro se convertir en pe\'dro , de


forma que el interprete SQL no tomar la comilla
como parte sintctica, sino como dato carcter.

METODOLOGA

En su lugar se propone usar la siguiente funcin.

Es muy difcil desarrollar una aplicacin segura a la


primera. Ni siquiera las grandes aplicaciones
escritas por programadores expertos estn libres de
fallos. La falta de tiempo y el nmero de
programadores implicados en la aplicacin son
factores habituales que juegan en contra de la
seguridad. Por este motivo son necesarias las
auditoras
de
cdigo,
para
localizar
vulnerabilidades en el cdigo.
En general, la auditora de cdigo se considera la
tarea ms difcil y compleja a la que puede
enfrentarse un programador. Actualmente existen
empresas de seguridad informtica que ofrecen
servicios de auditora de cdigo a precios
extremadamente altos, dependiendo de la
aplicacin. Sin embargo, en lo que respecta a la
inyeccin SQL, la labor es mucho ms fcil que
con otros tipos de vulnerabilidades.[1]
La auditora puede realizarse manualmente o
mediante herramientas existentes para tales fines.

La funcin inversa es stripslashes.


Estas prcticas son una medida de seguridad
habitualmente recomendada por autores de cdigo.
Sin embargo, NO ACONSEJA DEL TODO SU
USO, pues a menudo lleva a errores una mala
gestin de las barras.

2. Mysql_real_scape_string( $cadena)
Evita todos los caracteres especiales de la $cadena
argumento, teniendo en cuenta el juego de
caracteres usado en la conexin, de forma que sea
segura usarla con Mysql_query.
Coloca barras en los siguientes 7 caracteres:\x00
\n \r \ ' \x1a que se consideran peligrosos pues
pueden ser usados para varios tipos de ataques.
La funcin retorna la cadena con barras, pero la
variable original $cadena entrada no se modifica.
Algo parecido a esta funcin se puede realizar
colocando
comillas
dobles
de
la
forma $sql=SELECT * FROM tabla WHERE
usuario =' $_POST[usuario ] ' ;
3. Delimitar siempre los valores en las consultas.
Aunque el valor de la consulta sea un entero,
delimitarlo siempre entre comillas simples. Una
sentencia del estilo

Auditora de cdigo mediante herramientas

1. Magic_quotes

SELECT user FROM table WHERE iduser= $id


es mucho ms fcilmente inyectable que

Es una variable que se encuentra en el fichero .ini


de configuracin de PHP. Cuando su valor es On,
todas las entradas por parmetros sufrirn la
adicin de la barra invertida delante de la comilla
simple.

SELECT user FROM table WHERE iduser= '


$id '

Es lo mismo que realiza la funcin addslashes.

4. Verificar siempre los datos que introduce el


usuario

Si se espera recibir un entero, no confiar en que lo


sea, es mejor verificar con is_int(). Igualmente si es
un long con is_long(), o un char, un varchar, o
cualquier tipo con gettype(). Si se prefiere tambin
se puede convertir al tipo de dato que se espera
con intval() settype().
Comprobar tambin la longitud de las cadenas
con strlen() o su formato con strpos(). Con esto se
evitar posibles tcnicas avanzadas de inyeccin
SQL.
5. Crear libreras propias
Es muy pesado programar vigilando y revisando
constantemente cada variable, cada tipo, cada
caracter. Es mejor crear libreras propias, una clases
que acten como capa de abstraccin de todas estas
ideas necesarias a tener en cuenta constantemente.
Se programar ms rpido, se evitarn descuidos, y
simplemente se usa la seguridad que ya se
program.
6. PEAR Package DB - Paquete Bases de Datos
PEAR
El paquete DB del grupo PEAR va ms all de la
seguridad. Es una capa de abstraccin para bases de
datos. El inconveniente es que se depende siempre
de sus paquetes. Pero la ventaja es la
despreocupacin.
7. Filtrando los datos enviados por el usuario antes
de que estos sean procesados por el servidor, para
evitar que se puedan incluir y ejecutar textos que
representen nuevas sentencias SQL.
8. As mismo, es conveniente no utilizar las
consultas SQL basadas directamente en cadenas de
texto enviadas desde el navegador del usuario, sino
que se deberan construir todas las consultas en el
servidor
con
sentencias
preparadas
y/o
procedimientos almacenados parametrizados, que
encapsulen los parmetros que deberan evitar los
caracteres especiales que hubieran podido ser
introducidos dentro de ellos por un usuario
malicioso.
Es, de hecho, un error de una clase ms general de
vulnerabilidades
que
puede
ocurrir
en
cualquier lenguaje de programacin o script que

est

embebido

dentro

de

otro.

9. Valide siempre los datos especificados por el


usuario mediante comprobaciones de tipo, longitud,
formato e intervalo. A la hora de implementar
medidas de precaucin frente a la especificacin de
datos dainos, tenga en cuenta la arquitectura y los
escenarios de implementacin de la aplicacin.
Recuerde que los programas diseados para
ejecutarse en un entorno seguro pueden copiarse en
un entorno no seguro. Las sugerencias que se
muestran a continuacin deben considerarse
prcticas recomendadas:
No haga suposiciones sobre el tamao, tipo o
contenido de los datos que recibir la aplicacin.
Por ejemplo, debe hacer la siguiente evaluacin:

Cmo se comportar la aplicacin si


un usuario (malicioso o no) especifica un archivo
MPEG de 10 megabytes cuando la aplicacin
espera un cdigo postal.

Cmo se comportar la aplicacin si


se incrusta una instruccin DROP TABLE en un
campo de texto.

Compruebe el tamao y el tipo de los datos


especificados y aplique unos lmites adecuados.
Esto puede impedir que se produzcan saturaciones
deliberadas del bfer.

Compruebe el contenido de las variables de


cadena y acepte nicamente valores esperados.
Rechace las especificaciones que contengan datos
binarios, secuencias de escape y caracteres de
comentario. Esto puede impedir la inyeccin de
scripts y puede servir de proteccin frente a
explotaciones de saturacin del bfer.

Cuando trabaje con documentos XML,


valide todos los datos con respecto a su esquema a
medida que se vayan indicando.

No cree nunca instrucciones Transact-SQL


directamente a partir de datos indicados por el
usuario.

Utilice procedimientos almacenados para


validar los datos indicados por el usuario.

En 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 validacin deben rechazarse, y debe
devolverse un error al nivel anterior.

Implemente varias capas de validacin. Las


precauciones
que
tome
contra
usuarios
malintencionados ocasionales pueden resultar
ineficaces contra piratas informticos con
determinacin. Lo ms recomendable es validar los
datos especificados por el usuario en la interfaz de
usuario y, despus, en todos los puntos posteriores
en que atraviesen un lmite de confianza.[3]

Por ejemplo, la validacin de datos en una


aplicacin de cliente puede evitar la inyeccin de
scripts. Sin embargo, si en el siguiente nivel se
asume que ya se ha validado la entrada, cualquier
usuario malintencionado que sea capaz de eludir un
cliente puede disfrutar de un acceso sin
restricciones a un sistema.

No concatene nunca datos especificados por el


usuario que no se hayan validado. La
concatenacin de cadenas es el punto de entrada
principal de una inyeccin de scripts.
No acepte las siguientes cadenas en campos a
partir de los que puedan construirse nombres de
archivo: AUX, CLOCK$, COM1 a COM8, CON,
CONFIG$, LPT1 a LPT8, NUL y PRN.
DESARROLLO
Creamos un cdigo php declaramos las
variables:
nombre,
descripcin,
categora.con valor null
Capturamos el parmetro id
Establecemos una conexin con sql
Capturamos el valor del parmetro id
Al no declararse ningn filtro se va a poder
inyectar cdigo sql
La fila la cargamos en el documento html a
travs de una tabla, incluimmos el nombre,
descripcin, categora, precio

Abrimos el cdigo en el navegador


dirigiendo la ruta de nuestro programa:
URL:http://localhost/curso-php/sqlinyection/ejemplo2.php

Descargamos SQLMAP

Descomprimimos el sqlmap en la carpeta


donde tenemos guardado nuestro archivo .php

Abrimos el
infiltracin

terminal

realizamos

la

En el primer parmetro incluimos la expresin


regular y el segundo el valor que queremos evaluar
para solo aceptar nmeros

Guardamos nuestro reporte y verificamos que ya no


se pueden realizar infiltraciones sql injection

Obtenemos la base de datos

Filtramos los datos en nuestro programa para evitar


las infiltraciones con sql injection
Utilizamos una expresion regular utilizando la
funcin preg_match

CONCLUSIONES

Hay varias reglas de seguridad elementales que


debemos
tener
en
cuenta.
Principalmente proteger todas las puertas que
abrimos en nuestras pginas con la mejor de las
intenciones, que son las entradas en los
formularios o cualquier elemento que utilice la
etiqueta <input>.

Los ataques ms peligrosos en la actualidad que


atentan contra la seguridad de un sitio web son
dos: La Inyeccin de cdigo SQL y XSS,
abreviaturas de Cross-site scripting.

RECOMENDACIONES

No confiar en la entrada del usuario.


No utilizar sentencias SQL construidas
dinmicamente.
No utilizar cuentas con privilegios
administrativos.

No proporcionar mayor informacin de la


necesaria
REFERENCIAS BIBLIOGRFICAS

[1]http://www.genbetadev.com/seguridadinformatica/evita-los-ataques-de-inyeccionde-sql
[2]https://www.facebook.com/l.php?u=https
%3A%2F%2Fwww.owasp.org
%2Findex.php
%2FSQL_Injection_Prevention_Cheat_She
et&h=pAQF-cJN_.
[3]http://donnierock.com/2013/01/10/evitarsql-injection-en-php/