In caso di impedimento di SQLi, ho aggiunto questo tipo di controllo:
preg_replace("#([\[\]\|\.\,:'])#s", " ", $data);
Questo reg_ex dovrebbe sostituire tutto doloroso, perché la query principale è simile a
SELECT line FROM text WHERE tid LIKE '%{$data}%'
Ho messo diversi apostrofati codificati cercando di bypassare il mio assegno e sembra una buona protezione. Cosa ne pensi?
Non c'è motivo di implementare la tua logica di sanitizzazione nel 2016. Come sottolinea Aria, puoi usare mysqli_real_escape_string se vuoi disinfettare. La chiave qui è che questo NON è un mezzo efficace al 100% per prevenire SQLi.
Il modo corretto sarebbe utilizzare la libreria mysqli per parametrizzare le query, poiché ciò rende impossibile l'iniezione del primo ordine! Potresti vedere molti consigli per usare PDO per fare dichiarazioni preparate. È importante notare che le istruzioni preparate non sono le stesse delle query parametrizzate. Le istruzioni preparate sono solo istruzioni passate a un modulo che esegue l'igienizzazione per te.
Questo non vuol dire che l'igienizzazione non è utile, semplicemente non è utile per prevenire SQLi. Dovresti comunque farlo, per evitare lo scripting cross-site memorizzato. Elimina tutto ciò che un browser potrebbe riconoscere come HTML o JS o CSS se stai memorizzando un input non attendibile che potrebbe essere visualizzato in una pagina.
TL; DR Parametrizza le tue query per proteggerle da SQLi; preparali per la protezione da XSS memorizzato.
EDIT: Ho appena notato che la tua espressione regolare non sembra rappresentare un punto e virgola o un trattino, quindi potrei ottenere un'iniezione contro di essa abbastanza facilmente.
Questo non sfugge a tutti i caratteri richiesti per l'inserimento sicuro di una stringa nel database.
Puoi sfuggire ai $ data con mysqli_real_escape_string in aggiunta alla rimozione dei caratteri per assicurarti che non fallisca durante inserire.
Ecco l'elenco di caratteri .
Leggi altre domande sui tag php sql-injection