Non sono sicuro di capire cosa stai chiamando colonna vulnerabile. Ma proverò a rispondere alla tua domanda.
Prima di tutto, per individuare tale iniezione SQL, il modo più semplice è quello di iniettare operazioni matematiche, ad esempio:
www.vhul-web.com/index.php?id=1
Visualizza il risultato 1
www.vhul-web.com/index.php?id=2
Visualizza il risultato 2
www.vhul-web.com/index.php?id=2-1
Visualizza il risultato 1
In questo caso, possiamo dedurre che l'operazione matematica è stata probabilmente valutata, questo significa che l'applicazione rischia di essere vulnerabile.
Secondo passo è necessario determinare il numero di colonne selezionate nella query originale. Lo faccio utilizzando ORDER BY con valori diversi:
www.vhul-web.com/index.php?id=1 ORDER BY 4--
Non possiamo vedere nulla nel caso peggiore o una pagina di errore nel migliore dei casi, questo significa che ci sono meno di 4 colonne
www.vhul-web.com/index.php?id=1 ORDER BY 3--
Se possiamo vedere il risultato atteso (gli stessi dati che senza l'istruzione iniettata ORDER BY 3), significa che ci sono almeno 3 colonne. Significa esattamente 3 in questo esempio perché abbiamo anche meno di 4 colonne.
Ora vuoi visualizzare i risultati dell'iniezione UNION . Il motivo principale per cui è necessario inserire un id non esistente nella query è che in tali query lo sviluppatore spesso si aspetta solo un risultato dalla query SQL. Infatti, id , è spesso associato alla tabella Chiave primaria.
Quando si inserisce una query UNION , si aggiunge una seconda riga ai risultati non previsti, quindi è probabile che venga ignorata dallo script back-end, quindi non visualizzata.
Eseguendo una query su id non valido con un'istruzione UNION , lo script dovrebbe avere solo 1 risultato dal DB, risultante dalla query UNION .