Is the above code vulnerable to any kinds (error,blind,union based) of SQL injection?
No, ma solo perché sha1() si presenta sfortunatamente per produrre un output che non contiene mai metacaratteri SQL.
Il tuo codice di creazione di query non dovrebbe essere necessario conoscere i dettagli di questa implementazione. Dovrebbe essere in grado di sfuggire anche al $password_hash , in modo che la riga di codice funzioni autonomamente e possa essere verificata come corretta e sicura senza dover esaminare il contesto più ampio. Altrimenti, quando cambi il modo in cui viene calcolato quel $password_hash (ad esempio, per memorizzare un hash salato più sicuro), potresti scoprire di aver appena creato una vulnerabilità in quel codice di query. Creare un accoppiamento non necessario tra diversi bit di codice, potenzialmente in file diversi, è in generale una cattiva idea.
If the above code is safe, why do people still go for Prepared Statements etc...?
Perché le dichiarazioni preparate sono in genere più facili da leggere, comprendere e verificare; è più difficile omettere per errore una fuga. Confronto:
$query = "SELECT id,username FROM users WHERE username = '"
.mysqli_real_escape_string($link, $username)
."' AND password ='"
.mysqli_real_escape_string($link, $password_hash)
."'";
con:
$query = $mysqli->prepare('SELECT id,username FROM users WHERE username=? AND password=?')
$query->bind_param('ss', $username, $password_hash);
Anche se non sono un grande fan del particolare marchio di query parametriche di mysqli (in particolare il binding alle variabili anziché ai valori), il secondo mi sembra ancora più semplice e più gestibile.