Domanda

Se da una query SQL rimuovo tutti i caratteri ', esiste un altro modo per eseguire un attacco SQL injection sul database?

Come è possibile farlo?Qualcuno può darmi degli esempi?

È stato utile?

Soluzione

Si C'è.Un estratto da Wikipedia

"SELECT * FROM data WHERE id = " + a_variable + ";"

Da questa affermazione risulta chiaro che l'autore intendeva che a_variable fosse un numero correlato al campo "id".Tuttavia, se si tratta effettivamente di una stringa, l'utente finale può manipolare l'istruzione a suo piacimento, ignorando così la necessità di caratteri di escape.Ad esempio, impostando a_variable su

1;DROP TABLE users

eliminerà (eliminerà) la tabella "utenti" dal database, poiché l'SQL verrebbe visualizzato come segue:

SELECT * FROM DATA WHERE id=1;DROP TABLE users;

L'iniezione SQL lo è non un semplice attacco per combattere.Se fossi in te farei una ricerca molto attenta.

Altri suggerimenti

Sì, a seconda dell'istruzione che stai utilizzando.È meglio proteggersi utilizzando le procedure memorizzate o almeno le query parametrizzate.

Vedere WikiPedia per i campioni di prevenzione.

Sì, è assolutamente possibile.

Se hai un modulo in cui ti aspetti che un numero intero effettui la tua prossima istruzione SELECT, puoi inserire qualcosa di simile:

SCELTO DA thingy DOVE IDattributo=

  • 5 (buona risposta, nessun problema)
  • 5;Tavolo DROP users;(male male male...)

Il seguente sito web descrive in dettaglio ulteriori tecniche classiche di SQL injection: Foglio informativo di SQL Injection.

L'utilizzo di query parametrizzate o procedure memorizzate non è migliore.Queste sono solo query predefinite che utilizzano i parametri passati, che possono anche essere fonte di injection.E' descritto anche in questa pagina: Attaccare le procedure memorizzate in SQL.

Ora, se si sopprime la virgoletta semplice, si impedisce solo un determinato insieme di attacchi.Ma non tutti.

Come sempre, non fidatevi dei dati che arrivano dall’esterno.Filtrali a questi 3 livelli:

  • Livello di interfaccia per cose ovvie (un elenco di selezione a discesa è migliore di un campo di testo libero)
  • Livello logico per controlli relativi alla natura dei dati (int, stringa, lunghezza), permessi (questo tipo di dati può essere utilizzato da questo utente in questa pagina)...
  • Livello di accesso al database (escape semplice virgoletta...).

Buon divertimento e non dimenticare di controllare WikiPedia per le risposte.

/Vey

Ti suggerisco di passare le variabili come parametri e di non creare il tuo SQL.Altrimenti ci sarà sempre un modo per eseguire un'iniezione SQL, in modi di cui attualmente non siamo a conoscenza.

Il codice che crei è quindi qualcosa del tipo:

' Not Tested
var sql = "SELECT * FROM data WHERE id = @id";
var cmd = new SqlCommand(sql, myConnection);
cmd.Parameters.AddWithValue("@id", request.getParameter("id"));

Se hai un nome come il mio con una ' dentro.È molto fastidioso che tutti i caratteri ' vengano rimossi o contrassegnati come non validi.

Potresti anche voler dare un'occhiata a questo Domanda StackOverflow sulle iniezioni SQL.

SQL inline parametrizzato o procedure memorizzate parametrizzate rappresentano il modo migliore per proteggersi.Come altri hanno sottolineato, la semplice rimozione/escape del carattere di virgoletta singola non è sufficiente.

Noterai che parlo specificamente di procedure memorizzate "parametrizzate".Anche il semplice utilizzo di una procedura memorizzata non è sufficiente se si ripristina la concatenazione dei parametri passati della procedura.In altre parole, racchiudere la stessa identica istruzione SQL vulnerabile in una procedura memorizzata non la rende per nulla più sicura.È necessario utilizzare i parametri nella procedura memorizzata proprio come faresti con SQL inline.

Inoltre, anche se cerchi solo l'apostrofo, non vuoi rimuoverlo.Tu vuoi fuga Esso.Puoi farlo sostituendo ogni apostrofo con due apostrofi.

Ma le query/procedure memorizzate con parametri sono molto migliori.

Poiché si tratta di una domanda relativamente vecchia, non mi preoccuperò di scrivere una risposta completa ed esauriente, poiché la maggior parte degli aspetti di quella risposta sono stati menzionati qui da un poster o da un altro.
Trovo necessario, tuttavia, sollevare un'altra questione che non è stata toccata da nessuno qui: il contrabbando di SQL.In alcune situazioni, è possibile "introdurre" di nascosto il carattere virgoletta ' nella query anche se hai provato a rimuoverlo.In effetti, ciò potrebbe essere possibile anche se si utilizzassero comandi, parametri, procedure memorizzate, ecc. corretti.

Consulta il documento di ricerca completo su http://www.comsecglobal.com/FrameWork/Upload/SQL_Smuggling.pdf (divulgazione, sono stato il ricercatore principale su questo) o semplicemente google "contrabbando SQL".

...uh circa 50000000 in altri modi

forse qualcosa del genere 5; drop table employees; --

SQL risultante potrebbe essere qualcosa del tipo:select * from somewhere where number = 5; drop table employees; -- and sadfsf

(-- inizia un commento)

Si assolutamente:a seconda del dialetto SQL e simili, ci sono molti modi per ottenere l'iniezione che non utilizzano l'apostrofo.

L'unica difesa affidabile contro gli attacchi SQL injection è l'utilizzo del supporto di istruzioni SQL parametrizzate offerto dall'interfaccia del database.

Piuttosto che cercare di capire quali caratteri filtrare, mi atterrei invece alle query parametrizzate e rimuoverei completamente il problema.

Dipende da come metti insieme la query, ma in sostanza sì.

Ad esempio, in Java se dovessi fare questo (esempio deliberatamente eclatante):

 String query = "SELECT name_ from Customer WHERE ID = " + request.getParameter("id");

allora ci sono buone probabilità che tu ti stia esponendo a un attacco di iniezione.

Java dispone di alcuni strumenti utili per proteggersi da questi, come PreparedStatements (dove si passa una stringa come "SELECT name_ from Customer WHERE ID = ?" e il livello JDBC gestisce gli escape sostituendo il ?token per te), ma alcune altre lingue non sono così utili per questo.

Il fatto è che l'input autentico dell'apostrofo è forse genuino e devi sfuggirgli raddoppiandoli quando usi SQL inline nel tuo codice.Quello che stai cercando è uno schema regex come:

\;.*--\

Un punto e virgola utilizzato per terminare prematuramente l'istruzione autentica, alcuni SQL inseriti seguiti da un doppio trattino per commentare l'SQL finale dell'istruzione autentica originale.I trattini possono essere omessi nell'attacco.

Pertanto la risposta è:No, la semplice rimozione degli apostrofi non garantisce la sicurezza da SQL Injection.

Posso solo ripetere quello che hanno detto gli altri.SQL parametrizzato è la strada da percorrere.Certo, è un po' una seccatura codificarlo, ma una volta che lo hai fatto una volta, non è difficile tagliare e incollare quel codice e apportare le modifiche necessarie.Abbiamo molte applicazioni .Net che consentono ai visitatori del sito web di specificare un'intera gamma di criteri di ricerca e il codice crea al volo l'istruzione SQL Select, ma tutto ciò che avrebbe potuto essere inserito da un utente viene inserito in un parametro.

Quando ti aspetti un parametro numerico, dovresti sempre convalidare l'input per assicurarti che sia numerico.Oltre a contribuire alla protezione contro l'iniezione, la fase di convalida renderà l'app più facile da usare.

Se mai ricevi id = "hello" quando ti aspettavi id = 1044, è sempre meglio restituire un errore utile all'utente invece di lasciare che il database restituisca un errore.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top