L'utilità della riga di comando sqlcmd ha una funzione che consente la sostituzione dei parametri, dai parametri della riga di comando e dalle variabili di ambiente. link
Se un utente malintenzionato controlla le variabili, esiste un modo per scrivere gli script in modo che non siano vulnerabili all'iniezione SQL o che sia intrinsecamente insicuro in quella situazione?
Se l'attaccante controlla gli input SQLCMD, allora possono fare tutto ciò che le loro credenziali di accesso (autorizzate o rubate) possono fare. È solo un normale funzionamento.
Non farlo. Questa è una cattiva pratica se c'è qualche input dall'esterno nel tuo SQLCMD.
Se insisti su questo, se vuoi usare SQLCMD con la sostituzione di parametri da variabili di ambiente (forse), probabilmente vuoi sperimentare credenziali che possono ESEGUIRE solo all'interno di un certo schema limitato
CREATE SCHEMA FromSqlCmd AUTHORIZATION myuser
GRANT EXECUTE ON SCHEMA::[FromSqlCmd] TO [myschema_execute];
All'interno di ciascuna stored procedure, non concatenare MAI ciò che è passato a SQL dinamico.
NON mettere MAI i risultati in una tabella senza una whitelist; altrimenti ti stai aprendo per l'iniezione sql del secondo ordine.
Se si considera Powershell, quindi cjsommer.com ha un articolo su questo - ha scoperto che né il comando SQLPS di powershell è protetto dall'iniezione, anche con i parametri.
Se in realtà lasci che input - validato o meno - da altri faccia parte della tua linea di comando per SQLCMD, allora ti stai aprendo per l'iniezione dalla riga di comando !!! Il & il carattere è un modo per un prompt dei comandi di eseguire più comandi; provalo con
C: & cd \ & format /? & del /?
Ora immagina questo nel mezzo del tuo sqlcmd.
Si noti inoltre che Powershell utilizza; per separare i comandi.
Leggi altre domande sui tag sql-injection sql-server injection