evasione per iniezione SQL

Question

evasione per iniezione SQL

#1 da (3 voti)
#2 da (0 voti)

0

So che filtrare una cattiva parola chiave non è un buon approccio per prevenire l'iniezione SQL. Tuttavia, quando non potevo rispondere perché questo non è un buon approccio, ecco la mia regola:

1) Quando vedo ; , lo faccio a '' (in modo che nessuno possa creare un'altra riga di istruzioni SQL).

2) quando vedo ' , lo faccio a '' . (Credo che questo dovrebbe impedire la fuga di quotazioni).

3) Quando vedo * , lo faccio a &#42 (in modo che l'hacker non ottenga le informazioni sulla mia tabella).

4) Quando vedo -- , lo faccio a - (in modo che impedisca agli hacker di commentare la mia dichiarazione).

^ La ragione per cui sono venuto a conoscenza di queste 4 regole è a causa di una guida SQLi in qui

Consentitemi di fare quanto segue sul mio server durante l'analisi di un'istruzione SQL: db.exc("INSERT INTO name VALUES ('{}', '{}');".format(firsname, lastname))

E quando guardo la regola che ho impostato, penso che sia tecnicamente sicuro prevenire l'SQL injection su questa affermazione. Ho ragione? Se no, puoi fornire un modo per romperlo? (Conosco le migliori pratiche, ma non riesco a capire perché non lo sia.) Qualcuno può aiutarmi con un esempio?

sql-injection mysql

posta Alex 14.04.2018 - 23:58

fonte

2 risposte

0

I tuoi metodi di filtraggio non sono molto utili, dovresti usare metodi di sicurezza integrati invece di sostituire i caratteri da solo.

Puoi fare entrambe le ipotesi, ma ricorda che mysqli_query () non accetta automaticamente più istruzioni SQL, quindi corregge il tuo primo problema.

mysql_escape_string() corregge il tuo secondo problema e dovrebbe anche correggere una serie di altri problemi con i valori interpretati come aventi un'importanza maggiore di quanto dovrebbero.

Ciò che è attualmente in uso è noto come lista nera, non è del tutto efficace se non utilizzato in combinazione con altri metodi di mitigazione dell'iniezione SQL. Consiglio di utilizzare una whitelist se possibile. Quindi, ad esempio, si accettano solo numeri interi come input.

La lista nera è così:

I accept everything except for...

La lista bianca è così:

I disallow everything except for...

Quindi le whitelist, se usate correttamente, sono molto più efficaci di una lista nera. Ricorda che le iniezioni SQL sono molto, molto avanzate e esistono da molto tempo. Tutto quello che hai è una lista nera di 4 regole, se fosse così semplice prevenire tutti gli attacchi di SQL Injection con una lista nera contenente solo 4 regole, quindi SQLi non sarebbe un problema.

risposta data 11.05.2018 - 15:02

fonte

Leggi altre domande sui tag sql-injection mysql

Come posso forzare la re-autenticazione di un dispositivo specifico? [chiuso] SSL al server web di Cloudflare

score 3 · Accepted Answer

Un modo ovvio per violare questo: attacchi usando cose che non sono stringhe (per esempio numeri) dove l'utente deve inserire qualcosa come 45 (che viene manipolato nel codice come una stringa perché viene fuori alcuni HTML in questo modo, ma non è apostrofo delimitato nell'SQL perché è un campo di tipo numerico), ma può invece inserire un'intera subquery SQL (o una chiamata di procedura, o almeno alcune clausole aggiuntive ...).

Inoltre non sei affatto vicino al punto di comprendere i meta-caratteri. Ad esempio, l'utilizzo di -- per avviare un commento non è l'unico modo (non sono sicuro che lo sia anche nello standard SQL generale); un altro modo per iniziare un commento a riga singola (che MySQL supporta anche) è # , e non stai facendo nulla a riguardo. Vedi link

Altri problemi: supponiamo che tu sia riuscito a farlo in qualche modo "completamente". Quindi, in futuro, cambi i motori di database (o esegui semplicemente l'aggiornamento a una nuova versione) e il nuovo server di database supporta alcuni nuovi meta-caratteri (come inizio di un commento, come fine riga, come end-of-string, come delimitatore di sottoquery, come qualcos'altro ...), e improvvisamente la tua "soluzione" è di nuovo vulnerabile.

Smetti di provare a reinventare la ruota. Esistono istruzioni preparate / query con parametri per tutti i driver del database. Alcuni motori di database supportano stored procedure definite dall'utente, che non sono solo parametrizzate ma eseguono anche più velocemente delle normali stringhe SQL.

Se assolutamente deve combinare l'input dell'utente con SQL raw per qualche motivo (questo è raro e può essere evitato di solito essendo più intelligente con il tuo codice, ma in alcuni casi è possibile semplicemente utilizzare query parametrizzate), utilizzare una funzione di libreria ben testata per questo. Stai sostanzialmente cercando di ri-implementare mysql_escape_string , e il primo tentativo è andato storto anche .