Iniezione SQL con AND 1 = 1

La domanda specifica è l'iniezione SQL con AND 1 = 1 e non OR 1 = 1 . C'è una grande differenza qui in ciò che l'OP sta chiedendo. Se fossi il tuo insegnante e mi avessi fornito la risposta di JonathanMueller, avresti ottenuto un voto pessimo perché non capisci la domanda.

AND 1 = 1 è usato di solito in iniezioni SQL cieche . Questo è quando devi determinare tra uno stato vero o falso dal risultato dell'applicazione per capire quale sia il risultato reale. Non ottieni i dati elencati nel risultato, l'unica cosa restituita è uno stato di cambiamento.

Se provi a sfruttare un'iniezione SQL cieca con OR 1 = 1 fallirai perché l'uso principale di OR 1 = 1 è quello di creare un'istruzione sempre true per ottenere il maggior numero di dati dal database o per forzare una vera dichiarazione nel caso di uno script di accesso che viene sfruttato.

Un pratico esempio di exploit SQL cieco:

We use our example: http://www.site.com/news.php?id=7 Let’s test it: http://www.site.com/news.php?id=7 and 1=1 <--- this is always true and the page loads normally, that's ok.

http://www.site.com/news.php?id=7 and 1=2 <--- this is false, so if some text, picture or some content is missing on returned page then that site is vulnerable to blind sql injection.

Un altro esempio in cui provi a capire la versione di MySQL:

http://www.site.com/news.php?id=7 and substring(@@version,1,1)=4 This should return TRUE if the version of MySQL is 4. Replace 4 with 5, and if query return TRUE then the version is 5.

Esempi tratti da: link

Normalmente, vedresti la frase "OR 1 = 1" ". Il motivo è che se il programmatore non gestisce correttamente i parametri (come l'id utente), un utente malintenzionato potrebbe utilizzare OR 1=1 per restituire tutti i dati nella tabella.

Ad esempio, supponiamo di voler ottenere dettagli su un utente chiamato smith. La query potrebbe essere select * from user where id = '?' , in cui il punto interrogativo viene sostituito con un parametro dall'input dell'utente. Se l'utente malintenzionato ha superato smith' OR 1=1-- , l'SQL risultante sarebbe select * from user where id = 'smith' OR 1=1--' . In questo caso, la seconda citazione singola della query originale viene saltata perché fa parte di un commento e la query restituisce tutti i dati nella tabella utente.

Per dare un esempio (un po 'banale, senza testa) di sql injection, immagina questa query da qualche parte nel codice dell'app ...

select 1 from user where name='[NAME]' and password='[PASS]'

dopo che il Ragazzo Malvagio imposta i parametri con nome sopra a sua scelta, ottieni:

select 1 from user where name='admin' --' and password='[PASS]'

using the following chosen, unsanitized values:
[NAME]=' --' and password='[PASS]'
value of [PASS] variable is unimportant

Quindi, supponendo che la query abbia lo scopo di restituire 1 per il successo e il set vuoto per utente o pass non validi, un 1 verrebbe erroneamente restituito, consentendo a questo malvagio utente di accedere come account "admin".