Domanda:
La rimozione di spazi in una stringa proteggerà dall'iniezione SQL?
XaolingBao
2016-06-21 09:47:13 UTC
view on stackexchange narkive permalink

Ero curioso di sapere se fosse possibile proteggersi da un attacco SQL injection rimuovendo tutti gli spazi da un input String?

Ho letto su SQL Injection su OWASP, ma non menzionano nulla sulla rimozione degli spazi, quindi ero curioso di sapere perché avrebbe funzionato o meno?


Stavo esaminando questa domanda, che chiede informazioni su trim e la risposta in alto dice questo:

No, l'aggiunta di un trim non impedirà l'iniezione sql. trim rimuove solo lo spazio all'esterno della stringa.

  Seleziona * da una tabella dove il nome come '%' + @ SearchString + '%'  

Se @SearchString conteneva qualcosa come

  '' update aTable set someColumn = 'JackedUpValue' dove someColumn come ' 

Allora quando tu metti tutto insieme ed eseguilo dinamicamente otterrai

  Seleziona * da una tabella dove nome come '%' aggiorna aTable set someColumn = 'JackedUpValue' dove alcuneColumn come '%'  

Tuttavia, se hai preso quella stringa di ricerca

  update aTable set someColumn = 'JackedUpValue' dove someColumn come  

e hai eseguito l'operazione mostrata in questa domanda, non vorresti ottenere

  updateaTablesetsomeColumn = 'JackedUpValue'wheresomeColumnlike  

quale non dovrebbe essere eseguito, giusto?

Sono curioso di sapere se c'è qualche forma di SQL injection che potrebbe sconfiggerlo? C'è una parola comandi pericolosi? Se questo può essere sconfitto, rimuovere gli spazi aiuterebbe almeno un po 'con la difesa?

Nota: sto facendo questa domanda per pura curiosità, non per aggirare l'uso i metodi "appropriati" di SQL Injection Prevention.

Ma a cosa servirebbe questo?Il tuo obiettivo principale è raccogliere input, il secondo è impedire l'iniezione di SQL.O il tuo input deve mantenere gli spazi (quindi non puoi farlo) o non lo fa (nel qual caso rimuovili semplicemente).Tu stesso stai dicendo che questa non sarà la tua unica difesa, quindi prepara una difesa adeguata e dimentica questo "trucco per motivi di sicurezza".
questo è un problema risolto: parametrizza tutte le tue query
posso usare una tabulazione invece di uno spazio?
È bello vedere che sta arrivando il nuovo HBGary.Ragazzi molto "lungimiranti" ;-)
@JanDoggen Sto solo chiedendo un "what-if ..." Nel mio caso non ho bisogno di spazi, motivo per cui chiedo se rimuovere gli spazi, funzionerebbe.Sono anche curioso di disinfettare l'input solo per un certo intervallo di caratteri ASCII / unicode, proteggerei meglio dal momento che ci sono molti caratteri unicode spaziali sembra ...
Sebbene sia una domanda teorica valida, non ha assolutamente alcuna rilevanza pratica.C'è un modo a prova di bomba per proteggersi dall'iniezione SQL, che di solito è ancora più semplice di qualsiasi sanificazione alternativa;usalo senza doverti chiedere se qualche tecnica alternativa copre effettivamente tutte le tue basi.
È strano che io stia iniziando a ricevere voti negativi ora dopo tutti questi voti positivi .. Vorrei che le persone commentassero almeno il motivo ... Forse la mia modifica ???
"Non sto suggerendo che questa sia la mia unica forma di difesa, ma sono solo curioso di sapere dove questa forma di" Difesa "si inserisce nello spettro del buono o inutile. Non dovresti considerarla come una qualsiasi forma di difesa.Tuttavia, trattandosi di una domanda basata esclusivamente sulla curiosità scientifica, non c'è niente di sbagliato.
La rimozione di barre rovesciate, virgolette singole e doppie virgolette molto probabilmente impedirebbe l'iniezione di SQL.È anche pratico rimuovere i NUL per evitare errori di analisi delle query.Ma ovviamente la soluzione di facile manutenzione e meno sorprendente è passare gli argomenti della query separatamente (e contrassegnare la loro posizione con "?" Nella query), quindi il driver del client del database si occupa dell'escape o utilizza un ORM.
@XaolingBao Non ho una reputazione sufficiente per downvote, ma lo farei se potessi, perché la domanda sembra semplicemente dire 'So che ci sono tutti questi metodi adeguati che potrei usare, ma posso semplicemente usare questo pigro invece, cheparalizza ciò che i miei utenti sono in grado di inserire e omette palesemente di coprire quasi tutte le situazioni se dovessi effettivamente considerare il codice SQL della vita reale e set di caratteri estesi?
Come è stato accennato in precedenza, utilizzare sempre query con parametri.Vivi semplicemente partendo dal presupposto che l'SQL senza parametri verrà sempre sfruttato, perché francamente ci sono così tanti modi per abusarne che è impossibile proteggersi da tutti loro.Come semplice esempio, considera che filtri i numeri e l'attaccante ha bisogno di un "3" nella sua query per qualsiasi motivo.Cosa fa?"PIANO (PI ())".
@XaolingBao Immagino che i voti negativi siano perché, come affermato molte volte in risposta a questa domanda, è un problema risolto
@Jasper Avevo modificato quella pacca prima di vedere il tuo commento, per avere un po 'più di senso, ma sì, in realtà non lo sto considerando a meno che non abbia funzionato, quindi modificherò quella parte per rendere più chiaro che sto solo guardandoquesto da un punto di vista ipotetico, e come hai detto "curiosità scientifica"
@underscore_d Ho detto che sto usando procedure corrette, questa è solo una domanda ipotetica per vedere "cosa succederebbe se" dovessi rimuovere gli spazi, non per usare questo come un modo per sconfiggere SQL Injection, a meno che non abbia funzionato molto bene.
Sei risposte:
#1
+117
wireghoul
2016-06-21 10:40:22 UTC
view on stackexchange narkive permalink

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.

Grazie per l'interessante risposta, ma a che punto l'URL cambierà nell'istruzione della query e perché non potresti rimuovere gli spazi a quel punto?Inoltre, questo sembra interessare solo gli URL o può essere utilizzato anche nelle applicazioni?Non sono proprio sicuro che nell'applicazione qualcosa come "\ n" produca uno spazio dopo aver tentato di rimuovere gli spazi bianchi da una stringa ... Sono anche curioso se sei d'accordo con quanto segue riguardo alle iniezioni che non sono così grandiun affare e una "cosa del passato?"Credo che tutte le mie domande siano dichiarazioni preparate / parametrizzate.Grazie.
È un esempio web generico, perché hai fatto riferimento a owasp."Immagina" come l'input dell'utente è finito nella query.Come avvengono le SQL injection è una domanda molto diversa dal tuo OP.I metodi per sfruttare le SQL injection sono applicabili ovunque si verifichino SQL injection, che si tratti di un'applicazione Windows, un server FTP, un plug-in del lettore musicale o una pagina web.SQL injection è un problema molto attuale e sebbene gli sviluppatori siano sempre più consapevoli, è ancora una scoperta comune.
Capisco, non l'ho guardato correttamente e non mi ero reso conto che potevi fare solo id = 1 o altri comandi che erano così.Ho pensato che un'applicazione potrebbe essere in grado di proteggersi meglio da un attacco rispetto a una query URL, ma non sono sicuro di come funzioni in confronto.Dovrò cercare questo id = 1 e 1 = 1 business però .. Grazie mille.
+1 per "*** L'unico modo affidabile per prevenire l'iniezione di SQL è usare query parametrizzate ***" - sembra che non possiamo ripetere abbastanza!
@TobySpeight tranne che sembra che alcuni sostengano che le query parametrizzate non proteggono da tutte le forme di SQL Injection?
Non so nemmeno perché le persone continuano a provare a risolvere l'iniezione di SQL senza query parametrizzate, come se non ne avessero mai sentito parlare.Mi fa venire voglia di sfondare la mia faccia contro un tavolo di legno, insieme a quello stupido meme di Bobby Tables.
#2
+48
Julie Pelletier
2016-06-21 10:11:12 UTC
view on stackexchange narkive permalink

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).

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/41512/discussion-on-answer-by-julie-pelletier-would-removing-spaces-in-a-string-protec).
#3
+17
Anders
2016-06-21 12:45:02 UTC
view on stackexchange narkive permalink

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.

Grazie per la risposta, ma sembrava che tu potessi inserire piccole dichiarazioni, come nella risposta di wireghoul dove dice id = 1, ma non sono sicuro che possano ottenere le password in questo modo, e sono curioso di dove viene restituito l'input se lorol'hai fatto nella riga dell'URL?Nel tuo esempio con l'amministratore, avresti bisogno di conoscere le sue informazioni per accedere, quindi sono un po 'confuso cosa sta cercando di mostrare il tuo esempio?Sto usando dichiarazioni preparate, ma sono solo curioso ipoteticamente di quanto sarebbe buona la rimozione dello spazio e altre attività simili ... Grazie!
Nel mio esempio devi solo conoscere un nome utente (non la password) per accedere come tale utente.Questo è molto, molto brutto.Ci sono molte altre cose che potresti fare.Whireghoul ha alcuni esempi, così come Jimmy James.
"Questo è molto molto brutto", che significa nessuna password per admin lol?Che cosa significa esattamente "admin" - "in SQL?Già, sembra che sarebbe stato sconfitto da altri piccoli comandi.Grazie.
Questo è l'SQL che ottieni: `SELECT * FROM users WHERE username = 'admin' - AND password = ''`.Ma poiché `--` avvia un commento, la query che viene eseguita è` SELECT * FROM users WHERE username = 'admin'`.Quindi restituirà l'utente amministratore come se la password fosse stata abbinata, anche se non c'era password.
Grazie mille ... Questo ha molto senso ed è sporco ....:) ... Dato che ho modificato la mia domanda sulla disinfezione dell'input per consentire solo numeri e lettere, questo attacco e altri menzionaticon caratteri come "= e%" dovrebbe essere interrotto, giusto?Molte grazie!
#4
+13
JimmyJames
2016-06-21 18:54:52 UTC
view on stackexchange narkive permalink

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.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/41582/discussion-on-answer-by-jimmyjames-would-removing-spaces-in-a-string-protect-aga).
#5
+2
nvuono
2016-06-23 18:09:35 UTC
view on stackexchange narkive permalink

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.

#6
+1
user126572
2016-10-06 07:23:28 UTC
view on stackexchange narkive permalink

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.

Come rimuoverai i dati dal modulo cannonico?Non sarebbe solo un altro parser che può essere indotto a credere che i dati siano codice?L'aggressore dovrebbe creare un SQLi e quindi un parser cannonico fuorviare alla fine / all'inizio della stringa.È più problematico del semplice SQLi, ma non a prova di proiettile.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...