Identificación de la vulnerabilidad de inyección SQL utilizando el parámetro GET de la URL

  

Método 1: ¿Significa que al insertar un (') al final de un parámetro numérico de obtención en una URL (Ej: /agenda_dat.php?ID=10' ), si la página web muestra un mensaje de error de base o una página blanca, el sitio web es 100% vulnerable a SQLi, o podría ser que el sitio web NO sea vulnerable a SQLi?

Una página en blanco puede indicar que se ha activado una condición previa (protección contra SQLi), o podría indicar un error de lanzamiento.

Si hay un error de sintaxis SQL, entonces definitivamente ha encontrado una vulnerabilidad de SQLi.

Por ejemplo, el SQL involucrado puede parecerse a uno de estos, que son explotables.

select * from agenda where id=$id;
select * from agenda where id='$id';

  

Método 2: ¿Significa que al hacer lo siguiente

/agenda_dat.php?ID=10  (Original URL -> returns original page)
/agenda_dat.php?ID=12-2  (Returns the same page as the original one) 

     

¿El sitio web es 100% vulnerable a SQLi, o podría ser que el sitio web NO sea vulnerable a SQLi?

Si se evalúa la aritmética, entonces casi definitivamente estás viendo una vulnerabilidad de SQLi.

select * from agenda where id=$id;

Debería haberse escrito así, con el valor ? correcto pasado como un parámetro separado. Esto nunca produciría un error de sintaxis SQL.

select * from agenda where id=?;

Si descubre una vulnerabilidad de SQLi, la siguiente pregunta será, por supuesto, qué se puede lograr con un exploit. A veces puede terminar una declaración y agregar una nueva declaración al final.

0; delete from db; -- input data
select * from agenda where id=0; delete from db; -- resulting sql

Un exploit de múltiples enunciados de este tipo puede transferir datos confidenciales a un espacio de acceso público, o alterar y eliminar datos críticos que paralizan la operación.

En los sistemas donde se bloquean varias declaraciones ( ; separadas), un SQLi en una declaración de selección no le permite cambiar los datos directamente.

Sin embargo, con el uso de la fuerza bruta incremental puede determinar qué datos se encuentran en la base de datos y, finalmente, robar información confidencial, quizás incluso credenciales de inicio de sesión más altas. Además, un SQLi que no es útil puede ser una pista de que SQLi puede existir en otra parte de la aplicación.

1) Si hay algo en la página, es probable que haya algo mal, y probablemente SQLi. Sin embargo, si se trata de un error de base de datos, existe una gran posibilidad de que sea vulnerable a SQLi. Una página en blanco por otro lado no es necesaria una garantía de que es vulnerable. Tal vez el "artículo de noticias" o lo que sea no se haya encontrado y el sitio web simplemente devuelva una página en blanco.

También es necesario mencionar que existe una diferencia entre un error de base de datos y un error WAF, error HTTP, ... Sin embargo, los dos últimos no necesariamente significan una vulnerabilidad de SQLi.

2) Sí, esto tampoco debería ser aceptado por el código del lado del servidor. Y puede estar bastante seguro de que se está produciendo una vulnerabilidad de SQLi.