Usando base64 per evitare le iniezioni SQL?

Usa le variabili di binding per evitare l'SQL injection, come ad esempio:

UPDATE users SET JOB=?, SALARY=?, BONUS=?, COMM=? where id=someId 

Passa quindi l'input dell'utente JOB , SALARY , BONUS , COMM come parametri di bind.

Quello che vuoi fare è codificare l'input dell'utente in base64 e poi inserirlo nel database come base64? Ciò significherebbe interrogare il database, dovresti decodificare il materiale.

Un'altra opzione per codificare l'input dell'utente in base64, decodificare, quindi archiviare nel database. Questo non ti darà altro che spese generali e non impedirà l'iniezione SQL.

ATTENZIONE : archiviare le password in base64 codifica in un database è un crimine, non prendi nemmeno in considerazione di farlo, potresti anche memorizzare le password in testo non crittografato. Assumi un esperto di sicurezza dei dati, non vorresti finire tra i titoli della lunga lista di aziende violate! NB: NON SONO un professionista della sicurezza dei dati di professione.

Supponendo che l'aggressore usi quanto segue:

something'; drop table users; ---

la codifica base64 sarebbe

c29tZXRoaW5nJzsgZHJvcCB0YWJsZSB1c2VyczsgLS0t

Tutto bene finora, tuttavia, se dovessi interrogare questo valore, dovresti codificare / decodificare base64 nella query / set di risultati.

Ad esempio, supponendo che tu voglia selezionare tutte le righe in cui UINPUT è stato avviato con qualcosa , dovresti farlo quando il valore non è codificato in base64:

select USERS.* from USERS where UINPUT like 'something%'

e questo se fosse codificato:

select USERS.* from USERS where UINPUT like 'c29tZXRoaW5n%'

Dove c29tZXRoaW5n ovviamente è la codifica base64 per something , questo è noioso. Peggio ancora, la codifica base64 ha padding per stringhe che non hanno multipli di 3 caratteri, come = , il che significa che something funziona, qui, ma somethin ( c29tZXRoaW4= ) no!

Poiché la codifica base64 non può contenere spazi / virgolette, non è possibile iniettare, tuttavia, l'utilizzo di questo è noioso, le istruzioni preparate con le variabili di binding sono MOLTO meglio.

Questo potrebbe "funzionare" in un senso molto stretto della parola. Se base64 codifica tutto l'input dell'utente destinato alle query SQL, non riesco a vedere come sarebbe possibile eseguire un attacco SQLi poiché l'alfabeto base64 non contiene molti caratteri utili.

Ma guidare un chiodo in un pezzo di legno sbattendo la fronte contro di esso probabilmente anche "funzionerebbe", ma ti causerebbe molte sofferenze inutili. C'è uno strumento per questo - si chiama un martello. E c'è uno strumento per prevenire l'iniezione SQL - si chiama istruzioni preparate.