Con SQL Injection si intente l'inserimento di codice SQL all'interno di un altro comando SQL da parte di utenti “pericolosi” al fine di recuperare informazioni sulla struttura o sui dati del nostro SQL Server o per arrecare danno agli stessi.
Questo non significa assolutamente che SQL sia potenzialmente pericoloso ed un facile veicolo per malintenzionati; significa semplicemente che vi è la possibilità, in alcune circostanze, di far eseguire codice non previsto dalla nostra applicazione o pagina web.
Come i BOL (Books On Line) ci avvertono, ogni procedura che costruisce comandi SQL può ritenersi vulnerabile all'injection code, poiché SQL Server eseguirà ogni query ricevuta purchè sintatticamente corretta.
Qual'è, allora, lo scenario in cui può avvenire questa “iniezione” di codice maligno?

Facciamo un esempio.
Supponiamo di avere un'applicazione, o pagina web se preferiamo, dalla quale riceviamo l'imput dell'utente per ottenere l'elenco dei comuni appartenenti ad una provincia.
Nella casella di testo utilizzata per l'input dei dati scriveremo, ad esempio, "Brescia".
In parole povere l'istruzione che vorremmo far eseguire a SQL Server dovrebbe essere:

Select * from Comuni Where Provincia = 'miaProvincia' 

Dove miaProvincia sarà il testo digitato.
La mia applicazione creerà, quindi, la seguente stringa:

myQuery = “Select * from Comuni where Provincia = '” & txtProvincia.text & “'”

Il risultato passaro a SQL Server sarà, ovviamente:

Select * from Comuni where Provincia = 'Brescia'

Vediamo, ora, come rendere dannosa questa semplice istruzione.
Scriviamo, al posto del nome della città, questo testo:
Brescia'; drop table Comuni--
La nostra applicazione costruirà la query esattamente come prima:

myQuery = “Select * from Comuni where Provincia = '” & txtProvincia.text & “'”

ma il risultato finale sarà ben differente:

Select * from Comuni where Provincia = 'Brescia;' drop table comuni--

Il carattere “;” indica la fine di una query e l'inizio di una successiva.
Il due caratteri “-–“ hanno l'effetto di rendere tutto il rimanente codice un semplice commento e quindi di non essere interpretato.
In questo modo se anche la nostra query fosse stata un po' più complessa o avesse avuto delle clausole Where di verifica o altro, il risultato sarebbe stato identico!
Ma come difendersi da questo insidioso nemico?
Controllando e validando ogni input da parte dei nostri utenti?
Beh, direi che l'operazione potrebbe essere molto faticosa e poco efficace; inoltre, cercare di bloccare le parole chiave quali "drop", "truncate" ecc. potrebbe non bastare.
Appoggiamoci allora all'oggetto Command, aggiungendo tanti parameters alla sua collection quanti sono i parametri utilizzati dalla nostra stringa.
Il vantaggio primario di questa operazione è che, qualsiasi sia il valore passato ai parametri, questo verrà sempre trattato come semplice testo e non interpretato, neutralizzando ogni tipo di codice maligno.

Dim myConnection As New SqlConnection(…)
Dim myCommand As SqlCommand 
myCommand = new SqlCommand ("SELECT * from Comuni where Provincia=@Provincia", myConnection)
myCommand.Parameters.Add(new SqlParameter("@Provincia", txtProvincia.Text));

Ancor meglio, a mio avviso, sarebbe racchiudere l'intera istruzione all'interno di una StoredProcedure che accetti parametri:

Dim myConnection As New SqlConnection(…)
Dim myCommand As SqlCommand = myConnection.CreateCommand
myCommand.CommandType = CommandType.StoredProcedure
myCommand.CommandText = "SelezionaComuni"
Dim par As SqlParameter = myCommand.Parameters.Add("@Provincia", SqlDbType. VarChar)
par.Value = txtProvincia.text

Una StoredProcedure ci permetterà, inoltre, di validare direttamente il dato immesso: definendo, per esempio, un parametro come tipo Int, non sarà possibile inserirvi valori alfanumerici.
Impostando una lunghezza per un parametro (es. varchar(20)) non sarà possibile inserire testo più lungo del valore impostato (nel nostro esempio 20 caratteri). ecc.
A questo punto possiamo concludere che l'SQL Injection non è affatto un limite di SQL Server, ma un improprio utilizzo da parte di un utente che approfitta di una nostra superficiale organizzazione.