No estoy seguro de entender lo que está llamando columna vulnerable. Pero intentaré responder tu pregunta.
En primer lugar, para localizar dicha inyección SQL, la forma más sencilla es inyectar operaciones matemáticas, por ejemplo:
www.vhul-web.com/index.php?id=1
Muestra el resultado 1
www.vhul-web.com/index.php?id=2
Muestra el resultado 2
www.vhul-web.com/index.php?id=2-1
Muestra el resultado 1
En ese caso, podemos deducir que la operación matemática probablemente ha sido evaluada, lo que significa que la aplicación es probable que sea vulnerable.
Segundo paso, tiene que determinar el número de columnas que se seleccionan en la consulta original. Lo hago utilizando ORDER BY con diferentes valores:
www.vhul-web.com/index.php?id=1 ORDER BY 4--
No podemos ver nada en el peor de los casos o una página de error en el mejor de los casos, esto significa que hay menos de 4 columnas
www.vhul-web.com/index.php?id=1 ORDER BY 3--
Si podemos ver el resultado esperado (los mismos datos que sin la instrucción inyectada ORDER BY 3), esto significa que hay al menos 3 columnas. Lo que significa exactamente 3 en este ejemplo porque también tenemos menos de 4 columnas.
Ahora desea mostrar los resultados de su inyección UNION . La razón principal por la que necesita poner un id no existente en la consulta es que en tales consultas, el desarrollador a menudo espera solo un resultado de la consulta SQL. De hecho, id , a menudo se asocia con la clave principal de la tabla.
Cuando inyecta una consulta UNION , agrega una segunda fila a los resultados que no se espera, por lo que es probable que el script de back-end la ignore, por lo que no se muestra.
Al consultar un id no válido con una declaración UNION , la secuencia de comandos solo debe tener 1 resultado de la base de datos, como resultado de la consulta UNION .