No. La rimozione degli spazi non impedirebbe l'iniezione SQL, poiché ci sono molti altri modi per rendere il parser il tuo input. Vediamo un esempio. Immagina di avere un URL che utilizzava l'input fornito dall'utente in modo non sicuro in una query:

http: //example/index.php? Id = 1 => SELECT * dalla pagina dove id = 1

Nel tuo esempio l'attaccante userebbe spazi:

http: //example/index.php? id = 1% 20oppure% 201 = 1 => SELEZIONA * dalla pagina dove id = 1 o 1 = 1 .

La rimozione degli spazi comporterebbe la compressione dell'iniezione in una stringa.

Ora immaginiamo che l'attaccante abbia utilizzato un'altra forma di spazio bianco, ad esempio le tabulazioni:

http: //example/index.php? id = 1% 09o% 091 = 1 => SELEZIONA * dalla pagina dove id = 1 o 1 = 1 .

La rimozione degli spazi consentirebbe comunque l'iniezione.

A seconda della tecnologia in uso, l'aggressore potrebbe sostituire gli spazi con / ** / % 00 % 09 % 0a % 0d o qualsiasi numero di Unicode che causa la tokenizzazione da parte del parser SQL. Mentre l'esempio a cui si fa riferimento ha rimosso più di semplici spazi, l'esempio sopra menzionato sfrutta i commenti SQL per causare la tokenizzazione che non sono spazi bianchi. Saresti comunque vulnerabile.

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

Siamo nel 2016! Le SQL injection sono un ricordo del passato a meno che non si utilizzi un codice non sicuro.

Qualunque sia la lingua utilizzata, se si desidera impedire qualsiasi e tutte iniezioni SQL, utilizzare istruzioni preparate o qualsiasi altro tipo di associazione di dati.

Le istruzioni preparate separano la query dai dati, rendendo impossibile che i dati influenzino la query.

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

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

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

Diciamo che inserisco il nome utente admin '- . Ciò mi farebbe accedere come amministratore, senza utilizzare un solo spazio.

Come sottolinea wireghoul, dovresti rimuovere anche altri caratteri vuoti come tab. Ma come Julie Pelletier, usa solo affermazioni preparate. Cercare di inventare schemi intelligenti per fermare SQLi senza di essa potrebbe essere un gioco divertente, ma non ti darà mai la sicurezza che le dichiarazioni preparate fanno. Tutto il resto è solo una distrazione.

No . Supponiamo che tu abbia questo come SQL:

  "seleziona * da persone dove last_name = '" + surname + "'"  

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

  seleziona * da persone dove last_name =' 'OR (1 = 1) OR'a '=' ' 

Che viene eseguito in Oracle e MySQL (almeno) e restituisce tutte le righe della tabella.

Tuttavia, se prendessi quella stringa di ricerca

update aTable set someColumn = 'JackedUpValue' dove someColumn like ed eseguissi l'operazione mostrata in questa domanda, non ottieni

updateaTablesetsomeColumn = 'JackedUpValue'wheresomeColumnlike che non dovrebbe essere eseguito, giusto?

Come altri hanno sottolineato ci sono altri modi per ottenendo spazi bianchi in varie implementazioni del database SQL di cui dovresti tenere conto, come tabulazioni e \ n (newline). Quasi ogni motore di database accetterebbe volentieri:

  updateaTablesetsomeColumn = 'JackedUpValue'  

Potrebbero esserci vari caratteri Unicode che funzionano come spazi bianchi in base alle impostazioni di localizzazione in vari database, ma dovresti davvero scavare nei dettagli di implementazione per capirlo. Non c'è davvero alcun motivo per cercare di coprire tutti questi casi limite per la sostituzione di stringhe rispetto all'uso di query con parametri.

Quindi ecco un'idea. I server di database accettano la query SQL in arrivo e la eseguono attraverso un parser che genera 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 inteso dal programmatore.

Quindi la correzione è essere in grado di rilevare alberi di analisi insoliti. Percorri l'albero dopo aver analizzato e produci una stringa in forma canonica meno i valori dei dati. Calcola un hash SHA della stringa. Mantenere 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 modalità 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 più essere possibile SQL Inject.