Per sapere che un exploit SQL ha funzionato, devi essere sicuro che il codice che hai fornito sia effettivamente eseguito lato server.
Un'istanza di SQL injection potrebbe essere una query creata come
SELECT * FROM users WHERE username='{user}' AND password='{pass}';
Sostituendo, ad esempio, user=squeamish&pass=ossifrage con user=admin&pass=' OR ''=' , lo fai in modo che la query eseguita sia
... WHERE username='admin' AND password='' OR ''='';
che ha buone probabilità di ottenere il login dell'amministratore. Questa è una query.
Se sostituisci, come hai fatto, con ' OR 1=1; WAITFOR DELAY '00:00:05';# , (in realtà credo che # dovrebbe essere stato -, ma forse entrambe le sequenze di caratteri sono iniziatori di commenti validi? Ho dimenticato), ottieni
... WHERE username='' OR 1=1; WAITFOR DELAY '00:00:05';# other code ignored
e queste sono due query . Sintassi molto più potente, sì, dal momento che ora puoi eseguire qualsiasi query come seconda. Ma molti motori non hanno o non possono essere configurati per eseguire qualcosa oltre la prima query. Non avresti quindi alcun ritardo e quindi erroneamente concludi che l'exploit non ha funzionato.
Il tuo secondo tentativo fa anche uso del metodo "due query".
Per ottenere un ritardo significativo, è necessaria una funzione che richiederà molto tempo per essere eseguita. A seconda del motore, si potrebbe fare bene con:
' OR SLEEP(5)='
Questo produrrà una query di
... WHERE username='admin' AND password='' OR SLEEP(5)='' ...
che, per essere valutato, richiede che il motore restituisca il risultato di una sospensione (). Molto probabilmente la query fallirà, ma prima di farlo, aspetterà cinque secondi. Ecco come puoi automaticamente sapere che una stringa di query creata produce risultati migliori.
Ad esempio in MySQL ottieni
mysql> select 5=SLEEP(5);
+------------+
| 5=SLEEP(5) |
+------------+
| 0 |
+------------+
1 row in set (5.00 sec) <----