Come posso spiegare l'SQL injection senza gergo tecnico?

Il modo in cui lo dimostro per completare i non-tecnici è con una semplice analogia.

Immagina di essere un robot in un magazzino pieno di scatole. Il tuo compito è quello di prendere una scatola da qualche parte nel magazzino e metterla sul nastro trasportatore. I robot devono sapere cosa fare, quindi il programmatore ti ha fornito una serie di istruzioni su un modulo cartaceo, che le persone possono compilare e consegnare a te.

Il modulo ha il seguente aspetto:

Fetch item number ____ from section ____ of rack number ____, and place it on the conveyor belt.

Una richiesta normale potrebbe essere simile a questa:

Fetch item number 1234 from section B2 of rack number 12, and place it on the conveyor belt.

I valori in grassetto (1234, B2 e 12) sono stati forniti dalla persona che ha emesso la richiesta. Sei un robot, quindi fai ciò che ti viene detto: sali fino al rack 12, scendi fino a raggiungere la sezione B2 e prendi l'oggetto 1234. Torna quindi al nastro trasportatore e fai cadere l'oggetto su di esso .

E se un utente immettesse qualcosa di diverso dai valori normali nel modulo? Cosa succede se l'utente ha aggiunto istruzioni in loro?

Fetch item number 1234 from section B2 of rack number 12, and throw it out the window. Then go back to your desk and ignore the rest of this form. and place it on the conveyor belt.

Anche in questo caso, le parti in grassetto sono state fornite dalla persona che ha emesso la richiesta. Dato che sei un robot, fai esattamente ciò che l'utente ti ha appena detto di fare. Vai al rack 12, prendi l'oggetto 1234 dalla sezione B2 e gettalo fuori dalla finestra. Poiché le istruzioni ti dicono anche di ignorare l'ultima parte del messaggio, il bit "e posizionalo sul nastro trasportatore" viene ignorato.

Questa tecnica è chiamata "iniezione", ed è possibile a causa del modo in cui le istruzioni sono gestite - il robot non può dire la differenza tra istruzioni e dati , cioè le azioni che deve eseguire e le cose su cui deve fare quelle azioni.

SQL è un linguaggio speciale usato per dire al database cosa fare, in un modo simile a come abbiamo detto al robot cosa fare. In SQL injection, ci imbattiamo esattamente nello stesso problema: una query (una serie di istruzioni) potrebbe avere parametri (dati) inseriti in essa che finiscono per essere interpretati come istruzioni, causando un malfunzionamento. Un utente malintenzionato potrebbe sfruttarlo dicendo al database di restituire i dettagli di ogni utente, che ovviamente non è buono!

Per evitare questo problema, dobbiamo separare le istruzioni e i dati in modo che il database (o il robot) possa facilmente distinguere. Questo di solito viene fatto inviandoli separatamente. Quindi, nel caso del robot, leggerebbe il modulo vuoto contenente le istruzioni, identifica dove sono i parametri (cioè gli spazi vuoti) e lo memorizza. Un utente può quindi salire e dire "1234, B2, 12" e il robot applicherà tali valori alle istruzioni, senza consentire che vengano interpretate come istruzioni stesse. In SQL, questa tecnica è nota come query parametrizzate.

Nel caso del parametro "diabolico" che abbiamo dato al robot, ora solleva un sopracciglio meccanico con aria interrogativa e dice

Error: Cannot find rack number "12, and throw it out the window. Then go back to your desk and ignore the rest of this form." - are you sure this is a valid input?

Successo! Abbiamo fermato il "problema tecnico" del robot.

Uno dei modi più semplici per illustrare il problema dietro SQL-injection è usare un'immagine come questa. Il problema è la capacità di ricezione di separare i dati dal comando.

Ecco un'analogia non tecnica del mondo reale.

Stai per andare in banca per eseguire una transazione per conto del tuo capo. Il tuo capo ti ha dato una busta con le istruzioni per il cassiere.

Le istruzioni leggono:

Write the balance for account with number 8772344 on this paper.

Signed,
Boss

Lascia la busta fuori dalla tua vista per pochi minuti mentre vai in bagno. Un ladro apre la busta e aggiunge sopra la firma: "Trasferisci anche $ 500 dall'account 8772344 a un altro account con il numero 12747583.".

Ora viene visualizzato il messaggio completo:

Write the balance for account with number 8772344 on this paper.
Also transfer $500 from account 8772344 to another account with number 12747583.
Signed,
Boss

Il cassiere controlla la tua identificazione e verifica che tu sia una persona autorizzata per l'account in questione e segua le istruzioni nella lettera.

Il tuo capo è il codice del programma legittimo. Tu sei il codice del programma e il driver del database che sta consegnando il codice SQL al database. La lettera è il codice SQL che viene passato al database. Il ladro è l'attaccante. Il cassiere è il database. L'identificazione è in genere un login e una password per il database.

Se stai davvero spiegando a tua nonna, usa la scrittura di un assegno cartaceo come esempio. (Negli Stati Uniti) nel corso della giornata, dovresti scrivere numericamente l'importo in dollari in un campo, quindi dovresti scrivere la stessa cosa in parole. Ad esempio in un campo, si scriverebbe "100,00" e nel secondo campo più lungo, si scriverebbe "Cento dollari e zero centesimi". Se non hai utilizzato l'intero secondo campo lungo, devi tracciare una linea per impedire a qualcuno senza scrupoli di aggiungere il tuo importo scritto.

Se hai commesso l'errore di lasciare uno spazio nel secondo campo più lungo, qualcuno potrebbe modificare il campo numerico e quindi utilizzare lo spazio extra nel campo più lungo per riflettere quello. Il modificatore potrebbe ottenere più denaro di quanto previsto quando hai scritto il controllo.

L'iniezione SQL è la stessa cosa: un errore che consente alle persone non scrupolose di modificare un campo di immissione in modo che vengano restituite ulteriori informazioni rispetto a quelle previste dal programmatore originale.

L'idea che mi è venuta in mente inizialmente è stata spiegarla in termini di Mad Lib. Le storie in cui le parole sono tralasciate e per riempire gli spazi vuoti chiedi al gruppo le parole dei tipi indicati e scrivili, poi leggi la storia risultante.

Questo è il modo normale di compilare un Mad Lib. Ma cosa succederebbe se qualcun altro conoscesse la storia e quali spazi vuoti stavi compilando (o potessi indovinare)? Quindi, invece di una sola parola, cosa succede se quella persona ti ha dato qualche parola? E se le parole che ti hanno dato includessero un periodo che termina la frase? Se lo hai compilato, potresti scoprire che ciò che è stato fornito è ancora "adatto", ma cambia drasticamente la storia più di quanto non possa mai fare una sola parola che normalmente inseriresti. Potresti, se hai spazio, aggiungere interi paragrafi al Mad Lib e trasformarlo in qualcosa di molto diverso.

Questo, in termini non tecnologici, è l'iniezione SQL in poche parole. Fornisci alcuni "spazi vuoti" per i dati che verranno inseriti in un comando SQL, proprio come le parole in Mad Lib. Un utente malintenzionato immette quindi un valore che non è quello che ti aspetti; invece di un semplice valore da cercare, inserisce una parte di un'istruzione SQL che termina quella che hai scritto, quindi aggiunge il suo comando SQL dopo di ciò come una nuova "frase". La dichiarazione aggiuntiva può essere molto dannosa, come un comando per cancellare il database, o per creare un nuovo utente con molte autorizzazioni nel sistema. Il computer, non conoscendo la differenza, eseguirà semplicemente tutte le attività che è comandato da fare.

Spiegherei che è come dire al cassiere che il cliente ha sempre ragione e che dovrebbero fare tutto il possibile per soddisfare le necessità del cliente. Quindi, dal momento che non ci sono controlli sulla ragionevolezza della richiesta, quando un cliente arriva e dichiara di volere l'intero negozio gratuitamente, il cassiere carica tutto l'inventario sul loro camion per loro.

Non è una spiegazione perfetta, ma ha l'idea che al codice venga detto di fare qualsiasi cosa l'utente inserisca e che il cattivo utilizzi quella istruzione per farla franca.

Suppongo che dipenda davvero dal tipo di punto che stai cercando di trasmettere.

Un altro ottimo modo per spiegare qualcuno su qualsiasi cosa (incluso SQL Injection) è l'aiuto di personaggi dei cartoni animati e di incorniciare una storia intorno a loro.

Secondo me, questa è la migliore immagine disponibile su internet, spiegandola in un modo molto carino.

Fonte: link

Dipende tutto dal grado di non tecnico di cui stai parlando qui, ma di solito descrivevo l'iniezione SQL agli uomini d'affari qualcosa del genere -

"un punto debole nel modo in cui alcuni siti Web gestiscono l'input degli utenti (ad esempio dove inserisci il tuo nome in un modulo di registrazione) che può consentire a un utente malintenzionato di accedere al database che memorizza tutte le informazioni dell'utente per il sito"

se vogliono un po 'più di dettagli.

"Alcune applicazioni web non separano correttamente l'input dell'utente dalle istruzioni per il database, che possono consentire agli aggressori di istruire direttamente il database, attraverso le informazioni che compilano nel modulo del sito Web. Ciò può consentire all'utente malintenzionato di leggere gli altri utenti informazioni fuori dal database, o modificare alcune delle informazioni in là. "

Penso che tu possa ottenere l'effetto migliore semplicemente dimostrando l'attacco. Scrivi un formulare Web innocuo e mostra il risultato della query utilizzando l'input dell'utente. Quindi, dopo aver inserito il tuo input preparato, il tuo pubblico avrà una "aha-esperienza" dopo aver trovato le password nel risultato. Ho creato una pagina di dimostrazione , basta fare clic sulla "freccia successiva" per inserire un input preparato.

P.S. Se si scrive una pagina del genere da soli, prestare molta attenzione a non consentire ai tester di ottenere privilegi indesiderati. La cosa migliore è quando tu da solo eseguirai la demo sul tuo sistema locale con i privilegi di database più bassi possibili (non tutti i tipi di attacchi dovrebbero essere possibili, è solo una demo). Crea una white-list delle espressioni consentite.

Il database è come un genio magico (o, Oracle ) che garantisce i desideri. Abbiamo detto al nostro genio di concedere solo un massimo di tre desideri, ma se non verifichiamo ciò che la gente desidera, allora qualcuno potrebbe facilmente superarlo chiedendo qualcosa di intelligente come "altri cento desideri" o "desideri di tutti gli altri" .

Spiega come:

Il sistema può ricevere richieste con dati da qualsiasi utente per fare qualcosa con esso.

Il sistema stesso ha funzionalità per operare come cancellare o modificare i dati.

Un utente malintenzionato tenta di eseguire una di queste funzioni per ottenere o distruggere qualcosa.

Quindi l'attaccante inserisce comandi validi nelle richieste.

Il sistema esegue questi comandi, eseguendo qualsiasi cosa l'autore dell'attacco desideri.

Immagina una grande azienda che conserva tutti i suoi documenti in formato cartaceo in una grande stanza piena di schedari. Per recuperare o apportare modifiche ai file, qualcuno compilerà un semplice modulo di compilazione degli spazi vuoti e successivamente tale modulo verrà inviato a un impiegato che segue le istruzioni sul modulo.

Ad esempio:

Retrieve the billing records from start date _ _ _ to end date _ _ _ where the customer is _ _ _

Normalmente questo sarebbe qualcosa di simile a questo:

Retrieve the billing records from start date 01/01/2011 to end date 12/31/2011 where the customer is Billy Joe Bob

Ma nelle mani di una persona senza scrupoli, forse questo modulo potrebbe essere utilizzato per altri scopi, ad esempio:

Retrieve the billing records from start date 01/01/2011 to end date 12/31/2011 where the customer is Robert Mensas and also retrieve the credit card numbers for all customers

Facendo finta che il loro nome includa anche altri comandi possono dirottare il modulo di riempimento, e se l'impiegato non è stato addestrato a gestire questo tipo di cose allora forse semplicemente eseguiranno le istruzioni senza pensarci e consegneranno tutte le informazioni della carta di credito a un utente.

O, alternativamente:

Retrieve the billing records from start date 01/01/2011 to end date 12/31/2011 where the customer is Robert Mensas and also add $100,000 to Robert Mensas' account balance

Che ha un potenziale altrettanto pericoloso.

Il trucco con le iniezioni SQL è assicurarsi che il codice sia abbastanza intelligente da essere in grado di garantire che gli utenti non possano modificare l'intento dei comandi che si inviano al database e non sono in grado di recuperare i dati o apportare modifiche non dovrebbe essere permesso a.

A volte gli hacker inseriscono comandi di computer / programmazione in scatole su Internet per ingannare il sito Web nel fare qualcosa che non dovrebbe. Pertanto controlliamo le informazioni inserite sui siti web per quello che potrebbe essere un "comando".

... chi lo stai spiegando comunque?

Se non hai bisogno di farlo velocemente e hai a disposizione un pezzo di carta, dimostra semplicemente l'intera faccenda. SQL è abbastanza simile al linguaggio naturale, quindi prendi una semplice query e dimostra l'attacco:

 SELECT * FROM data WHERE key = $id

"$ id viene sostituito da ciò che è visibile qui punta al parametro URL . Normalmente, questo è un numero come 1 . Questo ci dà:"

 SELECT * FROM data WHERE id = 1

"Ora, se qualcuno inserisce più di un numero, viene incluso anche. Ad esempio, se qualcuno inserisce lì 1 OR 1 = 1 , otteniamo questo"

 SELECT * FROM data WHERE id = 1 OR 1 = 1

"Puoi vedere dove sta andando? Ora, su questo sistema, è anche possibile emettere più comandi, chiamati query, se li separi con un punto e virgola. Puoi indovinare cosa succede se qualcuno inserisce 1; DELETE EVERYTHING; ? "

 SELECT * FROM data WHERE id = 1; DELETE EVERYTHING;

"Il comando attuale è DROP DATABASE o DROP TABLE , ma ti viene l'idea."

Penso che l'esempio più semplice, più chiaro e divertente sia quello di "The Simpsons": le chiamate di scherzo di Bart:

link

Esempio:

Moe: [answering the phone] Moe's Tavern.

Bart: Hello, is Al there?

Moe: Al?

Bart: Yes, Al. Last name: Coholic.

Moe: Let me check... [calls] Phone call for Al. Al Coholic. Is there an Al Coholic here? [bar patrons laugh]

Moe: Wait a minute. [to phone] Listen, you little yellow-bellied rat jackass. If I ever find out who you are, I'll kill you! [hangs up]

Bart and Lisa: [laugh]

Homer: I hope you do find that punk someday, Moe.

Link di YouTube a una raccolta di quei messaggi telefonici per aiutare a scegliere l'esempio più adatto.

L'iniezione SQL è il luogo in cui un utente malintenzionato sta cercando di ottenere informazioni da un sito Web a cui non è autorizzato l'accesso.

Questo è come interrogare un'altra persona, dove l'interrogatore è l'utente malintenzionato e la persona interrogata è il sito web.

Le cose che l'interrogante potrebbe fare sono:

• Cerca lo sfondo della persona per trovare un punto debole
• Utilizza varie tecniche conosciute che hanno lavorato in passato su altre persone
• Trova nuove tecniche da usare

Alcuni punti deboli che possono essere interrogati possono essere:

• La formazione della persona
• L'intelligenza della persona
• La famiglia della persona
• Il tipo di persona che sono

Le cose da notare sono che ci sono interrogatori migliori di altri e alcune persone parleranno immediatamente mentre altri potrebbero non farlo mai.

Ben spiegando con un'analogia tecnica va bene, ma mi sembrerebbe un po 'lungo e zoppo.

Vorrei solo spiegare che si tratta di documenti rigidi o requisiti per limitare gli abusi nelle amministrazioni e nelle finanze.

Se è fatto in modo abbastanza rigoroso, hai meno pesci malvagi in grado di passare attraverso la rete.

Vorrei usare un semplice disegno con un pseudo codice molto semplice con caselle e frecce e spiegare i robot e l'analogia della scatola.

Il mio approccio per un non-techie:

Assume you are working in a large office building. Every clerk has an own key to its office (=SQL-query the programmer wanted to execute). Now someone takes a needle file and modifies his key a bit, i.e. removing a pin (=SQL-Injection, changing the SQL-query). This modified key can open different (or maybe all doors). So the clerk has access to more or all offices within this house and can read/change documents from other offices.

Probabilmente tutti sono abituati a usare chiavi e serrature, quindi dovrebbe essere facile da capire e dal mio punto di vista è una buona analogia con un'iniezione SQL.

Dipende sempre dalla persona che ti ascolta, ma questo è come lo spiegherei a lui / lei -

Immagina quando invii un telegramma con un messaggio come -

"Happy new year! Please take care. - Fred "

e qualcuno che non ha buone intenzioni in grado di accedere al tuo telegramma intercetterà e sostituirà le parole evidenziate con -

"Happy new year! Please send us money. - Fred "

Spero che aiuti! :)

Ecco il mio tentativo:

Sostituisci "sito" con "casa" e "attaccante | hacker" con "ladro".

L'iniezione SQL è il risultato di lasciare le finestre aperte (* con un'enorme luce al neon che dice "APERTA") di una casa mentre si dispone di porte anteriori e posteriori in acciaio inossidabile da 10 "spesse.

Il ladro vuole entrare in azione e rubare il tuo impianto stereo, ma prima, ha bisogno di capire come entrare, vede che le porte sono praticamente impossibili da rompere, tuttavia, dopo ulteriori indagini vede che le finestre sono ha aperto. Non può rubare i tuoi mobili (non in un pezzo almeno), ma può rubare il tuo impianto stereo, laptop, PC, ecc.

*) un po 'drammatico, lo so (: