Identificazione della vulnerabilità di SQL injection utilizzando il parametro GET dell'URL

Method 1: Does it mean that when inserting a (') at the end of a numerical get parameter in a URL (Ex: /agenda_dat.php?ID=10'), if the webpage shows a DBerror message or a white page, the website is 100% vulnerable to SQLi, or could it be that the website it is NOT vulnerable to SQLi?

Una pagina bianca può indicare che una condizione preliminare (protezione contro SQLi) è stata avviata, o potrebbe indicare un errore generato.

Se c'è un errore di sintassi SQL, hai sicuramente trovato una vulnerabilità SQLi.

Ad esempio, l'SQL coinvolto potrebbe apparire come uno di questi, che sono entrambi sfruttabili.

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

Method 2: Does it mean that when doing the following

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

the website is 100% vulnerable to SQLi, or could it be that the website it is NOT vulnerable to SQLi?

Se si calcola l'aritmetica, si sta quasi sicuramente considerando una vulnerabilità SQLi.

select * from agenda where id=$id;

Dovrebbe essere stato scritto in questo modo, con il valore ? corretto passato come parametro separato. Ciò non produrrebbe mai un errore di sintassi SQL.

select * from agenda where id=?;

Se si scopre una vulnerabilità SQLi, la prossima domanda ovviamente sarà ciò che si può ottenere con un exploit. A volte puoi terminare una dichiarazione e aggiungere una nuova istruzione alla fine.

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

Un tale exploit multi-statement può trasferire dati sensibili in uno spazio pubblicamente accessibile, oppure alterare e rimuovere i dati critici portando l'operazione all'arresto.

Su sistemi in cui sono bloccate più istruzioni ( ; separate), un SQLi su un'istruzione select non consente di modificare i dati direttamente.

Tuttavia, utilizzando la forza bruta incrementale è possibile determinare quali dati sono presenti nel database, eventualmente rubare informazioni sensibili, forse anche credenziali di accesso più elevate. Anche uno SQLi che non è utile può essere un indizio che SQLi possa esistere altrove nell'applicazione.

1) Se qualcosa sulla pagina è probabile, probabilmente c'è qualcosa che non va, e probabilmente SQLi. Tuttavia, se si tratta di un errore del database, si ha una grande possibilità che sia vulnerabile a SQLi. D'altra parte una pagina bianca non è necessaria per garantire che sia vulnerabile. Forse il 'notiziario' o qualsiasi altra cosa non è stata trovata e il sito web restituisce solo una pagina vuota.

Inoltre, occorre menzionare che c'è una differenza tra un errore del database e un errore WAF, errore HTTP, ... Gli ultimi due non significano necessariamente una vulnerabilità SQLi però.

2) Sì, anche questo non dovrebbe essere accettato dal codice lato server. E puoi essere abbastanza sicuro che una vulnerabilità SQLi stia succedendo.