Para saber que un exploit de SQL funcionó, debe asegurarse de que parte del código que proporcionó se esté ejecutando en el lado del servidor.
Una instancia de inyección SQL podría ser una consulta creada como
SELECT * FROM users WHERE username='{user}' AND password='{pass}';
Al reemplazar, digamos, user=squeamish&pass=ossifrage con user=admin&pass=' OR ''=' , lo haces para que la consulta ejecutada sea
... WHERE username='admin' AND password='' OR ''='';
que tiene buenas posibilidades de obtener acceso de administrador. Esta es una consulta una
Si reemplazas, como lo hiciste, con ' OR 1=1; WAITFOR DELAY '00:00:05';# , (en realidad creo que # debería haber sido -, pero tal vez ambas secuencias de caracteres sean iniciadores de comentarios válidos. Lo olvido), obtienes
... WHERE username='' OR 1=1; WAITFOR DELAY '00:00:05';# other code ignored
y estas son dos consultas . Sintaxis mucho más potente, sí, ya que ahora puede ejecutar cualquier consulta como la segunda. Pero varios motores no ejecutan, o pueden configurarse para no hacerlo, nada más allá de la primera consulta. Entonces no obtendrás ningún retraso y, por lo tanto, erróneamente concluirás que el exploit no funcionó.
Su segundo intento también hace uso del método de "dos consultas".
Para obtener un retraso significativo, necesita una función que tardará mucho tiempo en ejecutarse. Dependiendo del motor, puedes hacerlo bien con:
' OR SLEEP(5)='
Esto dará lugar a una consulta de
... WHERE username='admin' AND password='' OR SLEEP(5)='' ...
que, para ser evaluado, requiere que el motor devuelva el resultado de un estado de suspensión (). Lo más probable es que la consulta falle, pero antes de hacerlo, esperará cinco segundos. Así es como automáticamente puede saber que una cadena de consulta elaborada daría mejores resultados.
Por ejemplo, en MySQL obtienes
mysql> select 5=SLEEP(5);
+------------+
| 5=SLEEP(5) |
+------------+
| 0 |
+------------+
1 row in set (5.00 sec) <----