SQL INJECTIONS

inyecciones SQL son una de las vulnerabilidades ms comunes (web). Todas las
inyecciones SQL ejercicios, encuentran aqu, utilizan MySQL para back-end.
inyecciones SQL provienen de la falta de codificacin / escapar de la entrada
controlada por el usuario cuando se incluyen en las consultas SQL.
Dependiendo de cmo la informacin se agrega en la consulta, necesitar
diferentes cosas para romper la sintaxis. Hay tres maneras diferentes de
informacin en un eco sentencia SQL:

El uso de comillas: comilla simple o doble cotizacin.

El uso de copias de las garrapatas.
Directamente.

Por ejemplo, si desea utilizar la informacin como una cadena que puede hacer:

SELECT * FROM user WHERE name="root";

O

SELECT * FROM user WHERE name='root';

Si desea utilizar la informacin como un nmero entero que puede hacer:

SELECT * FROM user WHERE id=1;

Y, por ltimo, si desea utilizar la informacin como nombre de columna, tendr que
hacer:

SELECT * FROM user ORDER BY name;

O

SELECT * FROM user ORDER BY `name`;

Tambin es posible utilizar un nmero entero como cadena, pero ser ms lento:

SELECT * FROM user WHERE id='1';

La manera en que se hizo eco de la espalda, e incluso lo que se utiliza el separador,
decidir la tcnica de deteccin a utilizar. Sin embargo, no se dispone de esta
informacin, y usted tendr que tratar de adivinar. Tendr que formular hiptesis y
tratar de verificar ellos. Es por eso que pasar tiempo hurgando con los ejemplos en
el LiveCD es muy importante.
EJEMPLO 1

En este primer ejemplo, podemos ver que el parmetro es una cadena, y podemos
ver uno lnea de la tabla. Para entender el cdigo del lado del servidor, tenemos que
empezar a jugar alrededor:

Si aadimos caracteres adicionales, como 1234, usando? Name = root

1234, sin registro se muestra en la tabla. A partir de aqu, podemos suponer

que la solicitud utiliza nuestro valor en algn tipo de juego.

Si inyectamos espacios en la solicitud, utilizando? Name = root + (despus
de codificar), se visualiza el registro. MySQL (por defecto) ignorar espacios

finales en la cadena cuando se realiza la comparacin.

Si inyectamos una doble cita, usando? Name = root ", no hay registro es que

se muestra en la tabla.
Si inyectamos una comilla simple, usando? Name = root ', la tabla
desaparece. Probablemente nos separamos algo ...

A partir de esta primera parte, se puede deducir que la solicitud debe verse como:

SELECT * FROM users WHERE name='[INPUT]';

Ahora, vamos a verificar esta hiptesis.
Si estamos en lo cierto, las siguientes inyecciones deben dar los mismos resultados.

? Name = root ' and ' 1 '=' 1 '# (no se olvide de codificar #): en la cita la

consulta inicial ser comentada.

? Name = root ' and 1 = 1 # (no se olvide de codificar #): la cita en el

consulta inicial ser comentada y no necesitamos los 'en' 1 '=' 1 '.

? Name = root '# (no se olvide de codificar #): la cita en la primer consulta
ser comentada y no necesitamos el 1 = 1.

Ahora bien, estas peticiones no pueden devolver lo mismo:

? Name = root 'and' 1 '=' 0: la cita en la consulta inicial, se cerrar la una en

el extremo de nuestra inyeccin. La pgina no debe devolver ningn
resultado (Mesa de vaco), ya que los criterios de seleccin siempre

devuelven falso.
? Name = root 'and' 1 '=' 1 # (no se olvide de codificar #): en la cita la consulta
inicial ser comentada. Debemos tener el mismo como resultado de la consulta

anterior.
? Name = root 'or ' 1 '=' 1: la cita en la consulta inicial, se cerrar la una en el
extremo de nuestra inyeccin. o seleccionar todos los resultados, con el

segundo parte es siempre cierto. Se puede dar el mismo resultado, pero es poco
probable, ya que el valor se utiliza como un filtro para este ejemplo (en

oposicin a una pgina slo muestra un resultado a la vez).

? Name = root 'or ' 1 '=' 1 '# (no se olvide de codificar #): en la cita la consulta
inicial ser comentada. Debemos tener el mismo como resultado de la consulta
anterior.

Con todas estas pruebas, podemos estar seguros de que tenemos una inyeccin de
SQL. slo que esta formacin se centra en la deteccin. Usted puede mirar en otro
tipo de formacin PentesterLab, y aprender para explotar este tipo de problemas.
EJEMPLO 2
En este ejemplo, el mensaje de error regala la proteccin creado por el
desarrollador: error no ocupan espacio. Este mensaje de error aparece tan pronto
como el espacio es inyectada dentro de la peticin. Nos impide el uso de la ' and ' 1
Mtodo 1 '=', o cualquier toma de huellas digitales que utilizan el carcter de
espacio. Sin embargo, este filtrado es fcilmente dejado de lado, utilizando la
tabulacin (HT o \ t). Usted tendr que utilizar la codificacin, para usarlo dentro de
la peticin HTTP. El uso de esta simple derivacin, debe ser capaz de ver cmo para
detectar esta vulnerabilidad.

Ejemplo 3
En este ejemplo, los bloques de desarrollador espacios y tabulaciones. Hay una
manera de
pasar por alto este filtro. Puede utilizar los comentarios entre las palabras clave
para construir un vlido

solicitar sin ningn espacio o tabulacin. Los siguientes comentarios de SQL se

pueden utilizar:
/ ** /. Mediante la sustitucin de todo el espacio / tabulacin en los ejemplos
anteriores usando este
Comentario, usted debe ser capaz de probar para esta vulnerabilidad.

Ejemplo 4
Este ejemplo representa una tpica mala comprensin de cmo protegerse de SQL
inyeccin. En los 3 ejemplos anteriores, usando la funcin mysql_real_escape_string
habra evitado la vulnerabilidad. En este ejemplo, el desarrollador utiliz la misma
lgica. Sin embargo, el valor usado es un nmero entero y no se hizo eco entre sola
cita '. Dado que el valor se pone directamente en la consulta, utilizando
mysql_real_escape_string no impide nada. A continuacin, slo tiene que ser capaz
de aadir espacios y palabras clave de SQL para romper la sintaxis. El mtodo de
deteccin es realmente similar a la utilizada para la inyeccin SQL basada en la
cadena. Slo que no es necesario el citar al comienzo de la carga til.
Otro mtodo para detectar esta es jugar con el nmero entero. La solicitud inicial
es? Id = 2.
Al jugar con el valor 2, podemos detectar la inyeccin de SQL:

? Id = 2 # (# necesita ser codificado) debe devolver la misma cosa.

? Id = 3-1 debe devolver la misma cosa. La base de datos realizar

automticamente la sustraccin y obtendr el mismo resultado.

? Id = 2-0 debe devolver la misma cosa.
? Id = 1 + 1 (+ necesita ser codificado) debe devolver la misma cosa. La base
de datos se realizar automticamente la adicin y obtendr el mismo

resultado.
? Id = 2.0 debe devolver la misma cosa.

Y la siguiente no debe devolver los mismos resultados:

? Es = 2 + 1.
? Id = 3-0.

Ejemplo 5
Este ejemplo es muy similar a la anterior, la deteccin se refiere. Si nos fijamos en
el
cdigo, ver que el desarrollador trat de evitar la inyeccin de SQL mediante el
uso de una
expresin regular:

if (!preg_match('/^[0-9]+/', $_GET["id"])) {
die("ERROR INTEGER REQUIRED");
}
Sin embargo, la expresin regular utilizada es incorrecta; slo asegura que la
Identificacin del parmetro comienza con un dgito. El mtodo de deteccin
utilizado anteriormente se puede utilizar
para detectar esta vulnerabilidad.

Ejemplo 6
Este ejemplo es al revs. El desarrollador hizo un error en la regularidad la
expresin de nuevo:

if (!preg_match('/[0-9]+$/', $_GET["id"])) {
die("ERROR INTEGER REQUIRED");
}
Esta expresin regular slo asegura que el parmetro id termina con un dgito
(Gracias al signo $). No garantiza que el comienzo del parmetro es vlido (Falta ^).
Se pueden utilizar los mtodos aprendidos previamente. Slo tiene que aadir un
nmero entero al final de su carga til. Este dgito puede ser parte de la carga til o
colocado despus de un comentario de SQL: 1 o 1 = 1 # 123.

Ejemplo 7
Otro y ltimo ejemplo de una mala expresin regular:

if (!preg_match('/^-?[0-9]+$/m', $_GET["id"])) {
die("ERROR INTEGER REQUIRED");
}
Aqu podemos ver que el principio (^) y el final ($) de la cadena estn
correctamente comprobado. Sin embargo, la expresin regular contiene el
modificador PCRE_MULTILINE (/metro). El modificador multine slo confirma que una
de las lneas que contienen solamente se un entero, y los siguientes valores sern,
por tanto vlidos (gracias a la nueva lnea en ellos):

123\nPAYLOAD;
PAYLOAD\n123;
PAYLOAD\n123\nPAYLOAD.

Estos valores deben ser codificada cuando se utiliza en un URL, pero con el uso
decodificacin y las tcnicas vistas anteriormente que debe ser capaz de detectar
este vulnerabilidad.