[ SQl Injection ] | Evadiendo pantallas de login

Hoy vengo a hablar sobre una vulnerabilidad muy conocida, sql injection, actualmente existe mucha información en internet sobre esta vulnerabilidad, sin embargo, la mayoría de los posts que he encontrado se dedican a hacer uso de herramientas como sqlmap sqlninja  para realizar una explotación automática de la vulnerabilidad, en este caso veremos como podemos realizarla de forma manual.

¿Qué es Sql Injection?

La vulnerabilidad de sqlinection ( sqli ) se puede definir como el acceso a información dentro de una base de datos para la que no estamos autorizados introduciendo consultas  hacia la base de datos ( que en principio no estaban autorizadas ), buscando en OWASP podemos encontrar esta definición.

SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input in order to effect the execution of predefined SQL commands.

OWASP

Atacando un formulario de Login simple

Sabiendo una definición de Sqli pasaremos a ver como podemos explotarla. Si tenemos conceptos sobre web deberíamos de saber que existen dos métodos para enviar información en HTTP ( hay muchos más, pero estos son los más usados ):

  • GET: La información de los parámetros se muestra en la url
  • POST: La información no es mostrada por la URL

Teniendo en cuenta esta principal diferencia, podemos deducir que si la web usa GET, será más sencillo atacar el formulario ( solo sería modificar una url ), en el caso de que utilice POST, tenemos que utilizar Burp Suite o Zap

Para comprobar esto enviaremos un usuario de prueba ( obviamente erroneo )

SQLI_bypasslogin_3

 

Al ver que no se modifica la url, pasaremos a configurar Burp Suite y realizar el mismo proceso para observar los campos que se envían en las peticiones

SQLI_bypasslogin_2

El siguiente paso sería modificar los valores de username  password  para intentar provocar un fallo en la base de datos ( que será mostrado en la web ) e identificar la vulnerabilidad existente, para ello cambiaremos los valores por una simple 

SQLI_bypasslogin_4

 

SQLI_bypasslogin_5

 

Como podemos ver aparece un error de SQL, por lo cual podemos deducir que la base de datos a leído el carácter ‘  y ha llegado a un error, en este caso vamos a utilizar un filtro muy común.

‘ or 1=1 #

Este filtro de SQli lo que realiza es una comparación booleana dentro de la consulta a la base de datos, si descomponemos la consulta entenderemos mejor lo que sucede:

  • ‘ –> Nos encontramos cerrando la consulta legítima a la base de datos ( la que comprueba el usuario y contraseña)
  • or –> Establecemos el tipo de comparación booleana
  •  1 = 1 –> Establecemos un valor que sea True
  • # –> Cerramos la consulta

Lo que sucederá es que se ejecutará de modo que o el usuario es correcto ( no lo sabemos ) o 1=1 es verdadero ( como lo segundo si es verdadero entraremos)

SQLI_bypasslogin_6

Al enviar la petición recibiremos algunas más para cambiar al index

Y efectivamente estamos dentro

SQLI_bypasslogin_9

Anuncios

Un comentario sobre “[ SQl Injection ] | Evadiendo pantallas de login

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión /  Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión /  Cambiar )

Conectando a %s