La rimozione di spazi in una stringa protegge dall'iniezione SQL?

No. Rimuovere gli spazi non impedirebbe l'iniezione SQL, poiché ci sono molti altri modi per far sì che il parser elabori i tuoi input. Vediamo un esempio. Immagina di avere un URL che utilizzava input non autorizzato dall'utente in una query:

link = > SELECT * from page where id = 1

Nel tuo esempio l'utente malintenzionato usa spazi:

link = > %codice%.

Rimuovere gli spazi collasserebbe l'iniezione in una stringa.

Ora immaginiamo che l'attaccante abbia usato un'altra forma di spazio bianco, cioè le schede:

link = > %codice%.

Rimuovere gli spazi consentirebbe comunque l'iniezione.

A seconda della tecnologia in uso, l'attaccante può sostituire gli spazi con SELECT * from page where id = 1 or 1=1 SELECT * from page where id = 1 or 1=1 /**/ %00 %09 o qualsiasi numero di unicode che causa la tokenizzazione dal parser SQL. Mentre l'esempio di riferimento ha rimosso più che semplici spazi, l'esempio di cui sopra sfrutta i commenti SQL per causare la tokenizzazione che non è uno spazio bianco. Saresti comunque vulnerabile.

L'unico modo affidabile per prevenire l'SQL injection è utilizzare query parametrizzate.

Siamo nel 2016! Le iniezioni SQL sono una cosa del passato a meno che non si utilizzi un codice non sicuro.

Qualunque sia la lingua che usi, se vuoi impedire qualsiasi iniezioni di tutte , usa istruzioni preparate o qualsiasi altro tipo di associazione di dati.

Le istruzioni preparate separano la query dai dati, rendendo impossibile l'influenza dei dati sulla query.

Per rispondere direttamente alla tua domanda, la rimozione degli spazi ridurrebbe le iniezioni SQL (quando si utilizzano codici e librerie obsoleti), ma sicuramente limiterebbe il testo di input (senza spazi da nessuna parte).

Limiterà il problema, ma non lo eliminerà. Si consideri la seguente situazione:

$un = str_replace(" ", "", $_POST["username"]);
$pw = hash($_POST["password"];
$sql = "SELECT * FROM users WHERE username = '$un' AND password = '$pw'";

Diciamo che posto il nome utente admin'-- . Questo mi collegherebbe come amministratore, senza usare uno spazio singolo.

Come sottolinea wireghoul , è necessario rimuovere anche altri caratteri vuoti come la scheda. Ma come sottolinea Julie Pelletier , basta usare le istruzioni preparate. Cercare di creare schemi intelligenti per fermare SQLi senza di esso potrebbe essere un gioco divertente, ma non ti darà mai la sicurezza che le istruzioni preparate fanno. Tutto il resto è solo una distrazione.

No . Supponiamo che tu abbia questo come SQL:

"select * from people where last_name = '" + surname + "'"

Se inserisco: 'OR(1=1)OR'a'=' nell'input si trasforma in:

select * from people where last_name = ''OR(1=1)OR'a'=''

Che esegue in Oracle e MySQL (almeno) e restituisce tutte le righe dalla tabella.

However if you took that search string

update aTable set someColumn='JackedUpValue' where someColumn like and performed the operation shown in this question, wouldn't you get

updateaTablesetsomeColumn='JackedUpValue'wheresomeColumnlike which should not execute, right?

Come altri hanno sottolineato, ci sono altri modi per ottenere spazi vuoti in varie implementazioni del database SQL di cui dovresti tenere conto come schede e \n (newline). Quasi tutti i motori di database accettano volentieri:

update
aTable
set
someColumn='JackedUpValue'

Potrebbero esserci vari caratteri Unicode che funzionano come spazi bianchi basati su impostazioni di localizzazione in vari database ma dovresti davvero scavare nei dettagli di implementazione per capirlo. Non c'è davvero alcun motivo per provare a coprire tutti questi casi limite per la sostituzione di stringhe usando solo le query parametrizzate.

Quindi ecco un'idea. I server di database accettano la query SQL in entrata e la eseguono attraverso un parser che risulta in un albero di analisi. Quindi trasformano l'albero in un piano ed eseguono il piano.

L'essenza dell'iniezione è che il parser produce un albero diverso da quello voluto dal programmatore.

Quindi la correzione deve essere in grado di rilevare insoliti alberi di analisi. Cammina l'albero dopo l'analisi e crea una stringa in forma canonica meno i valori dei dati. Calcola un hash SHA della stringa. Mantieni una tabella di hash noti per l'utente dell'applicazione / database. Avvisa o interrompi se il server vede un hash sconosciuto.

Ovviamente, c'è un problema di avvio. Quindi il programmatore dovrebbe eseguire l'applicazione in una modalità di test, estrarre gli hash dopo un test esaustivo e caricare il server con gli hash all'avvio dell'applicazione. Quindi attiva abort-on-new-hash e non dovrebbe essere più possibile iniettare SQL.