Vulnerabilidades de OWASP Top 10. A1: 2017 - Inyecciones (Parte 1)

La descripción de vulnerabilidades es una cosa, pero tratar de encontrar una vulnerabilidad y trabajar con ella es un asunto completamente diferente. Es para estos fines que se crean y desarrollan aplicaciones especiales en las que las vulnerabilidades se dejan deliberadamente atrás. Si escribe en el motor de búsqueda la consulta "Aplicación especialmente vulnerable", no encontrará una docena de enlaces.

En esta serie, comenzaremos a analizar las vulnerabilidades de OWASP Top 10, y utilizaré una aplicación tan intencionalmente vulnerable como campo de pruebas. En mi caso será OWASP Mutillidae II. Esta no es la mejor opción, pero las vulnerabilidades están estructuradas exactamente como sea necesario para fines educativos.



Da tu mano

Entonces, la primera vulnerabilidad son las inyecciones. OWASP Mutillidae II presenta varias opciones, y comenzaremos con el más simple "SQLi extract Data"> "User Info (SQL)".
Ante nosotros está la ventana de autenticación habitual, con lo que interactúa a diario:



No tenemos un nombre de usuario o contraseña, nada. Pues bien, registremos en este sitio. Crearé un usuario con el nombre debajo de cero273 y la contraseña 123:



Genial Creamos una cuenta, la inscripción solemne "1 filas insertadas" sugiere que se ha agregado una fila, aparentemente a la tabla, porque una gran cantidad de cuentas es más fácil de almacenar en el DBMS.

Ahora inicie sesión con nuestra nueva cuenta en el sistema. Exitoso, genial.
Cuando trabajamos con una página web, siempre debemos recordar que nuestra interacción no se limita al contenido de la página. También hay una barra de direcciones, por ejemplo. En el que podemos notar muchas cosas interesantes:

http://127.0.0.1/mutillidae/index.php?page=user-info.php&username=belowzero273&password=123&user-info-php-submit-button=View+Account+Details 


Por ejemplo, vemos que la contraseña se transmite en texto claro. Esto es malo, ya que el tráfico puede ser interceptado. Pero tal vez no sea un desastre: el tráfico estará envuelto en TLS.
Intentemos reemplazar la contraseña justo en la línea, por ejemplo, esta pieza:

 username=belowzero273&password=123 


en

 username=belowzero273&password=12345 


La contraseña, por supuesto, ahora es incorrecta, y recibimos el error correspondiente: y esto es malo. Es malo, porque con la ayuda de THC-Hydra, de la que hablé aquí , podemos obtener esta contraseña sustituyéndola en esta línea sin ninguna forma. Pero esto no siempre puede conducir a un resultado positivo en un período de tiempo aceptable.

No tenemos tanto tiempo, así que intentemos algo más. Agregue un signo de apóstrofe a nuestra contraseña incorrecta:

 username=belowzero273&password=123 


en

 username=belowzero273&password=12345' 


Ahora tenemos un error completo:



No hay nada malo con los errores. ¿De qué otra forma diagnosticar un mal funcionamiento si no vemos comentarios de la aplicación? Pero tales errores no deberían ser visibles para los usuarios y atacantes.

Ahora vemos que, de hecho, cuando hacemos clic en el botón "Enviar" en segundo plano, se ejecuta la siguiente solicitud:

 SELECT * FROM accounts WHERE username='belowzero273' AND password='12345' 


Los apóstrofes destacan las variables de cadena. Nuestra aplicación web no filtra los datos que ingresa el usuario y, con nuestro apóstrofe adicional, infringimos la solicitud. Ahora que sabemos cómo se ve esta consulta en segundo plano, debemos descubrir cómo cambiarla para obtener la información que necesitamos de la base de datos.

Tenga en cuenta que la solicitud contiene la función y, es decir, ambas variables deben ser correctas, ya que esta es una combinación de inicio de sesión y contraseña. Es lógico.

Echemos un vistazo rápido a esta consulta:

 SELECT * FROM accounts WHERE (username='belowzero273' AND password='12345') OR 1='1 


Hemos agregado una condición que siempre se cumple: 1 = 1. Y la solicitud se ejecutará en dos casos: adivinamos la combinación de nombre de usuario y contraseña, o 1 = 1. Es decir, siempre se ejecutará.

Resulta que lo siguiente se puede especificar como contraseña:

 ' or 1='1 


El apóstrofe al final de la línea ya no es necesario, la lógica de la aplicación web lo pondrá por nosotros. Boom! Y obtuvimos una selección de la base de datos con todas las cuentas:



Genial, ahora tenemos inicios de sesión y contraseñas de todos los que están registrados en esta aplicación. Y lo que es peor, las contraseñas aquí están claras.

¿Qué tiene de malo eso? Y el hecho de que la mayoría de las personas usan los mismos nombres de usuario y contraseñas para todos los sitios. Y al haberse registrado de esta manera en un sitio vulnerable, pueden perder el acceso a todos sus sitios.

También puede experimentar con esta vulnerabilidad, por ejemplo, busque una contraseña de administrador. Para hacer esto, sustituya el inicio de sesión:

 admin' or 1='1 


Es decir, estamos buscando una entrada en la base de datos donde el nombre de usuario sea admin y la contraseña sea cualquiera.

   ! 


Las contraseñas no siempre se almacenan en texto claro, pero eso no significa que la autenticación se realice de forma segura. Veamos el segundo ejemplo en OWASP Mutillidae II "Autenticación de omisión de SQLi"> "Iniciar sesión".

La autenticación se puede omitir generando una solicitud correspondiente. Más recientemente, creamos una cuenta debajo de cero273, y ahora especifiquemos como inicio de sesión:

 ' or ('a' = 'a' and username='belowzero273') -- 


Aquí verificamos la condición obviamente correcta - a = a, y el inicio de sesión - debajo de cero273, y también cortamos la parte de solicitud con la ayuda de "-".

Presione Entrar e inicie sesión con éxito en el sistema a pesar de que no hemos especificado su contraseña en ningún lugar.

Tan fácil

A veces los clientes preguntan, ¿es realmente tan fácil omitir la autenticación en nuestro sitio? Por lo general, respondo la pregunta con la pregunta: "¿Estás seguro de que esto no ha sucedido ya?" Las inyecciones no están accidentalmente en la parte superior de la calificación OWASP, ya que estas vulnerabilidades, como regla, tienen consecuencias desastrosas si se implementan.

En la práctica, por supuesto, todo es algo más complicado que en estos ejemplos. Pero es sobre ejemplos tan básicos que la comprensión de problemas más profundos comienza a tomar forma. Continuaremos la próxima vez.

Lea el blog del autor en este enlace .

Source: https://habr.com/ru/post/es419387/


All Articles