Sql Protezione da iniezione con solo str_replace

Sto studiando SQL injection e ho provato nel mio codice PHP questa query:

$condition = str_replace(["'","\\"],["\\'","\\\\"], @$_GET['q']); $query = "SELECT * FROM dummy_table WHERE dummy_column = '$condition'"; 

Il set di caratteri DB e tabelle è impostato su UTF8.

Non posso iniettare nulla, qualcuno può aiutarmi per favore?

EDIT: Come sottolineato da GarethD, questo sfuggirebbe prima 'e che \, permettendo l'iniezione, che dire di questo str_replace?

 $condition = str_replace(["\\","'"],["\\\\","\\'"], @$_GET['q']); 

Questo esempio isolato è invulnerabile all'iniezione.

Ma devi capire che la protezione dall'iniezione sql non è solo una sostituzione di un personaggio . E le circostanze possono essere diverse da quelle che stai prendendo al momento per scontate. Pertanto, il tuo codice diventerebbe vulnerabile a lungo termine, a causa degli svantaggi essenziali di questo metodo :

  • la sostituzione dei caratteri è solo una parte della formattazione richiesta
  • questa particolare sostituzione può essere applicata solo alle corde, lasciando le altre parti assolutamente non protette.
  • tale sostituzione è esterna all'esecuzione di una query, significa che è soggetta a un errore umano di qualsiasi tipo.
  • tale sostituzione è una misura essenzialmente separabile, significa che può essere spostato troppo lontano dall'esecuzione effettiva della query e infine dimenticato.
  • questo tipo di fuga è sobject ad attacchi di codifica , rendendo la soluzione troppo limitata in uso.

Non c'è nulla di sbagliato nella sostituzione dei caratteri di per sé, ma solo se è usato come parte della formattazione completa; applicato alla parte di query corretta; e fatto da un driver di database, non da un programmatore; proprio prima dell'esecuzione.


Le funzioni che hai proposto nei commenti sono un buon passo, ma ancora insufficiente, essendo soggetti agli inconvenienti sopra elencati, rendendoli inclini a tutti i tipi di errori umani.

E l'SQL injection non è l'unico problema con questo approccio, è anche un errore di usabilità, in quanto questa function rovinerebbe i tuoi dati, se usati come incarnazioni di citazioni di magia tardiva, o far gonfiare il tuo codice, se usato per formattare each variabile a destra nel codice dell'applicazione.

Tali funzioni possono essere utilizzate solo per elaborare un segnaposto , ma ovviamente non mediante l'utilizzo di una function di sostituzione homebrewed, ma una function appropriata fornita dall'API del database.