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 è prendere una scatola da qualche parte nel magazzino e metterla sul nastro trasportatore. Ai robot deve essere detto cosa fare, quindi il tuo programmatore ti ha fornito una serie di istruzioni su un modulo cartaceo, che le persone possono compilare e consegnarti.

Il modulo ha questo aspetto:

Recupera il numero di articolo ____ dalla sezione ____ dello scaffale numero ____ e posizionalo sul nastro trasportatore.

Una richiesta normale potrebbe essere simile a questa:

Recupera il numero di articolo 1234 dalla sezione B2 del rack numero 12 e posizionalo sul nastro trasportatore.

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

Ma cosa succede se un utente inserisce qualcosa di diverso dai valori normali nel modulo? E se l'utente vi avesse aggiunto delle istruzioni?

Recupera il numero di articolo 1234 dalla sezione B2 dello scaffale numero 12 e lancia fuori dalla finestra. Quindi torna alla tua scrivania e ignora il resto di questo modulo. e posizionalo sul nastro trasportatore.

Anche in questo caso, le parti in grassetto sono state fornite dalla persona che ha rilasciato il 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 lo butti 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 vengono gestite le istruzioni: il robot non è in grado di distinguere tra istruzioni e dati , cioè le azioni che deve eseguire e le cose su cui deve eseguire tali azioni.

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

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

Nel caso del parametro "malvagio" che abbiamo dato al robot, ora sollevava un sopracciglio meccanico con aria interrogativa e diceva

Errore: impossibile trovare il numero di rack " 12 e lanciarlo dalla finestra. Quindi torna alla scrivania e ignora il resto di questo modulo. " - sei sicuro che sia un input valido ?

Successo! Abbiamo fermato il "glitch" del robot.

Uno dei modi più semplici per illustrare il problema alla base di SQL injection è usare un'immagine come questa. Il problema è la capacità di ricezione delle estremità 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 dicevano:

  Scrivi il saldo del conto con numero 8772344 su questo foglio. Firmato, capo  

Lasci la busta fuori dalla tua vista per qualche minuto mentre vai in bagno. Un ladro apre la busta e aggiunge sopra la firma: "Trasferisci anche $ 500 dal conto 8772344 a un altro conto con il numero 12747583".

Ora il messaggio completo dice:

  Scrivi il saldo del conto con il numero 8772344 su questo foglio. Trasferisci inoltre $ 500 dal conto 8772344 a un altro conto con il numero 12747583. Firmato, capo  

Il cassiere controlla la tua identificazione e verifica che tu sia un persona autorizzata per l'account in questione e segue 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. è 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 come esempio la scrittura di un assegno cartaceo. (Negli Stati Uniti) nel corso della giornata, si scriveva l'importo in dollari numericamente in un campo, quindi si scriveva la stessa cosa a parole. Ad esempio, in un campo, scrivere "100,00" e nel secondo campo, più lungo, scrivere "Cento dollari e zero centesimi". Se non hai utilizzato l'intero campo del secondo lungo, tracceresti una linea per impedire a qualcuno senza scrupoli di aggiungere all'importo scritto.

Se hai commesso l'errore di lasciare dello spazio nel secondo , campo più lungo, qualcuno potrebbe modificare il campo numerico e quindi utilizzare lo spazio extra nel campo più lungo per rifletterlo. Il modificatore potrebbe ottenere più denaro di quanto volevi quando hai scritto l'assegno.

L'iniezione di SQL è la stessa cosa: un errore che consente a persone senza scrupoli di modificare un campo di immissione in modo che tornino loro più informazioni rispetto al programmatore originale previsto.

L'idea che mi è venuta in mente per prima era di spiegarlo in termini di Mad Lib. Le storie in cui le parole vengono tralasciate e per riempire gli spazi vuoti chiedi al gruppo parole del tipo indicato e le scrivi, quindi leggi la storia risultante.

Questo è il modo normale per compilare un Mad Lib. Ma cosa succederebbe se qualcun altro conoscesse la storia e quali spazi vuoti stavi riempiendo (o potessi indovinare)? Allora, invece di una singola parola, cosa succederebbe se quella persona ti desse qualche parola? E se le parole che ti hanno dato includessero un punto che termina la frase? Se l'hai compilato, potresti scoprire che ciò che è stato fornito "si adatta" ancora, ma cambia drasticamente la storia più di quanto qualsiasi parola che normalmente inseriresti potrebbe mai fare. Potresti, se avessi spazio, aggiungere interi paragrafi al Mad Lib e trasformarlo in qualcosa di molto diverso.

Questo, in termini non tecnici, è SQL injection in poche parole. Fornisci alcuni "spazi vuoti" per i dati che verranno inseriti in un comando SQL, proprio come le parole in un Mad Lib. Un attaccante quindi immette 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 come una nuova "frase". L'istruzione aggiuntiva può essere molto dannosa, come un comando per eliminare il database o per creare un nuovo utente con molte autorizzazioni nel sistema. Il computer, non conoscendo la differenza, eseguirà semplicemente tutti i compiti che gli è stato ordinato di fare.

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

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

Fonte: http://xkcd.com/327/

Lo spiegherei come se dicessi a un cassiere che il cliente ha sempre ragione e che dovrebbe fare tutto il possibile per soddisfare le esigenze del cliente. Quindi, poiché non ci sono controlli sulla ragionevolezza della richiesta, quando un cliente entra e dice di volere l'intero negozio gratuitamente, il cassiere carica tutto l'inventario sul proprio camion per loro.

Non lo è. è una spiegazione perfetta, ma si ha l'idea che al codice venga detto di fare tutto ciò che l'utente inserisce e quindi il cattivo usa quell'istruzione per scappare con la merce.

Immagino che sia davvero dipende dal tipo di punto che stai cercando di capire.

Tutto dipende dal grado di non tecnico di cui parli qui, ma di solito descriverei SQL injection agli uomini d'affari qualcosa sulla falsariga di -

"una debolezza nel modo in cui alcuni siti web gestire l'input degli utenti (ad es. 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 desidera un po 'più di dettagli di quello.

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

Penso che tu possa ottenere l'effetto migliore solo dimostrando l'attacco. Scrivi un modulo web dall'aspetto 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 "esperienza aha" dopo aver trovato le password nel risultato. Ho creato una pagina demo di questo tipo, fai clic sulla "freccia successiva" per inserire un input preparato.

P.S. Se scrivi una pagina del genere da solo, fai molta attenzione a non consentire ai tester di ottenere privilegi indesiderati. La cosa migliore è quando solo tu 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 lista bianca delle espressioni consentite.

Il database è come un genio magico (o, Oracle ) che esaudisce i desideri. Abbiamo detto al nostro genio di esaudire solo un massimo di tre desideri, ma se non verifichiamo ciò che le persone desiderano, qualcuno lo supererebbe facilmente chiedendo qualcosa di intelligente come "altri cento desideri" o "desideri di tutti gli altri" .

Spiegalo facilmente come:

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

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

Un attaccante cerca di eseguire una qualsiasi di queste funzioni per ottenere o distruggere qualcosa.

Pertanto l'attaccante inserisce comandi validi nelle richieste.

Il sistema esegue questi comandi, eseguendo ciò che desiderava l'attaccante.

Immagina una grande azienda che conserva tutti i suoi registri in formato cartaceo in una grande stanza piena di schedari. Per recuperare o apportare modifiche ai file, qualcuno compilerà un semplice modulo da compilare e quindi quel modulo verrà inviato a un impiegato che segue le istruzioni sul modulo.

Ad esempio :

Recupera i record di fatturazione dalla data di inizio _ _ _ alla data di fine _ _ _ dove si trova il cliente _ _ _

Normalmente questo diventerebbe qualcosa in questo modo:

Recupera i record di fatturazione dalla data di inizio 01/01/2011 alla data di fine 31/12/2011 in cui il cliente è Billy Joe Bob

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

Recupera i record di fatturazione dalla data di inizio 01/01/2011 alla data di fine 31/12/2011 dove il cliente è Robert Mensas e recupera anche i numeri di carta di credito per tutti i clienti

Fingendo che il loro nome sia uguale o include altri comandi che possono dirottare il modulo di compilazione e se l'impiegato non è stato addestrato a gestire questo genere di cose, forse eseguirà semplicemente le istruzioni senza pensarci e consegnerà tutte le informazioni della carta di credito a un utente.

Oppure, in alternativa:

Recupera i record di fatturazione dalla data di inizio 01/01/2011 alla data di fine 12 / 31/2011 dove il cliente è Robert Mensas e aggiunge anche $ 100.000 al saldo del conto di Robert Mensas

che ha un potenziale altrettanto pericoloso.

Il trucco con le SQL injection è assicurarsi che il tuo codice sia abbastanza intelligente da essere in grado di garantire che gli utenti non possano modificare l'intento dei comandi che stai inviando al database e non siano in grado di recuperare dati o apportare modifiche che non dovrebbero essere autorizzati a farlo.

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

... a chi lo stai spiegando comunque?

Se non hai bisogno di farlo velocemente e hai un pezzo di carta a disposizione, fai una dimostrazione del tutto. SQL è abbastanza simile al linguaggio naturale, quindi basta fare una semplice query e dimostrare l'attacco:

  SELECT * FROM data WHERE key = $ id  

" $ id viene sostituito da tutto 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 ci mette più di un semplice numero, anche questo viene incluso. Ad esempio, se qualcuno ci mette 1 OR 1 = 1 , otteniamo questo "

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

" Puoi vedi dove sta andando? Ora, su questo sistema, è anche possibile emettere più comandi, chiamati query, se li separa semplicemente con un punto e virgola.Riesci a indovinare cosa succede se qualcuno mette in 1; DELETE EVERYTHING; ?"

  SELEZIONA * DA dati WHERE id = 1; ELIMINA TUTTO;  

"Il comando effettivo è DROP DATABASE o DROP TABLE , ma hai capito."

Penso che l'esempio più semplice, chiaro e divertente sia tratto da "The Simpsons": scherzi di Bart:

https://en.wikiquote.org/wiki/List_of_Simpsons_Prank_Calls

Moe: [rispondendo al telefono] Moe's Tavern.

Bart: Ciao, c'è Al ?

Moe: Al?

Bart: Sì, Al. Cognome: Coholic.

Moe: Fammi controllare ... [chiama] Telefonata per Al. Al Coholic. C'è un Al Coholic qui? [gli avventori del bar ridono]

Moe: Aspetta un minuto. [al telefono] Ascolta, piccolo topo dal ventre giallo. Se mai scoprissi chi sei, ti ammazzo! [riattacca]

Bart e Lisa: [ridono]

Homer: Spero che un giorno troverai quel punk, Moe.

In che modo questa è una buona analogia? Un "nome" che viene ripetuto con noncuranza senza controllare provoca un comportamento non intenzionale.

YouTube collega a una raccolta di quegli scherzi telefonici per aiutare a scegliere l'esempio più adatto.

SQL injection è il luogo in cui un utente malintenzionato tenta di ottenere informazioni da un sito Web a cui non è autorizzato ad accedere.

È come interrogare un'altra persona, in cui l'interrogante è l'utente malintenzionato e la persona che viene interrogata è il sito web.

Le cose che l'interrogatore potrebbe fare sono:

• Fare ricerche sul background della persona per trovare un punto debole
• Usa varie tecniche conosciute che hanno funzionato in passato su altre persone
• Trova nuove tecniche da usare

Alcuni punti deboli possono essere la persona interrogata:

• 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 subito mentre altre potrebbero non farlo mai.

Spiegare bene con un'analogia tecnica va bene, ma suonerei un po 'lungo e noioso.

Vorrei solo spiegare che è questione di scartoffie 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.

Userei un semplice disegno con uno pseudo codice molto semplice con caselle e frecce, e spiegare i robot e l'analogia con la scatola.

Il mio approccio per un non tecnico:

Supponi di lavorare in un grande edificio per uffici. Ogni impiegato ha una propria chiave per il proprio ufficio (= query SQL che il programmatore voleva eseguire). Ora qualcuno prende un file ago e modifica un po 'la sua chiave, ad es. Rimuovendo un pin (= SQL-Injection, cambiando la query SQL). Questa chiave modificata può aprire diverse (o forse tutte le porte). Quindi l'impiegato ha accesso a più o tutti gli uffici all'interno di questa casa e può leggere / modificare documenti da altri uffici.

Tutti sono probabilmente abituati a usare chiavi e serrature, quindi dovrebbe essere facile da capire e dal mio punto di vista è una buona analogia con una SQL injection.

Il canale YouTube Live Overflow ha un fantastico video chiamato "Injection Vulnerabilities - or: How I got a free Burger". Descrizione video:

Una sera ho ordinato del cibo e ho iniettato per sbaglio un hamburger nell'ordine. Il ragazzo delle consegne ha confuso un commento come un altro elemento nell'elenco degli ordini e lo ha fatto. Anche se non era associato alcun prezzo.

Ecco il mio tentativo:

Sostituisci "site" con "house" e "attacker | hacker" con "burglar".

SQL injection è il risultato di lasciare le finestre aperte (* con un'enorme luce al neon che dice "APERTO") di una casa mentre hai porte anteriori e posteriori in acciaio inossidabile spesse 10 ".

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

*) un po 'drammatico, lo so (:

Dipende sempre dalla persona che ti ascolta, ma è così che glielo spiegherei -

Immagina di inviare un telegramma con un messaggio come -

"Felice anno nuovo! Fai attenzione. - Fred "

e qualcuno che non ha buone intenzioni che fosse in grado di accedere al tuo telegramma avrebbe intercettato e sostituito le parole evidenziate con -

"Felice anno nuovo! Inviaci denaro. - Fred "

Spero che aiuti! :)