Non sono un tecnico e vorrei la tua esperienza nel capire questo. Recentemente ho letto un articolo dettagliato su SQLi per un documento di ricerca.
Mi sembra strano. Perché si verificano ancora così tante violazioni dei dati tramite l'iniezione SQL? Non c'è nessuna correzione?
Non esiste una soluzione generale per SQLi perché non esiste una soluzione per la stupidità umana. Esistono tecniche consolidate che sono facili da usare e che risolvono i problemi (in particolare il binding dei parametri), ma bisogna ancora usare queste tecniche. E molti sviluppatori non sono consapevoli dei problemi di sicurezza. La maggior parte si preoccupa che l'applicazione funzioni e non si preoccupi molto della sicurezza, specialmente se rende le cose (anche leggermente) più complesse e comporta costi aggiuntivi come il test.
Questo tipo di problema non è limitato a SQLi ma lo troverai con buffer overflow, controllo dei certificati, XSS, CSRF .... È più costoso fare una programmazione sicura a causa dei test aggiuntivi e delle competenze aggiuntive richieste dallo sviluppatore (quindi più costoso). E finché il mercato lo preferisce a buon mercato e non si preoccupa molto della sicurezza, si ottengono soluzioni economiche e insicure. E mentre la sicurezza del design aiuta molto a renderlo migliore, gli sviluppatori spesso lavorano attorno a questo progetto perché non lo capiscono ed è solo a modo loro.
Perché non è un problema.
Quando è stata l'ultima volta che una società con una vulnerabilità di SQL injection è stata trascinata in tribunale e schiaffeggiata con una multa per essere imprudente con i dati degli utenti, e gli amministratori sono stati avvisati, multati o bloccati per negligenza?
Quando è stata l'ultima volta che un'azienda ha perso un grosso contratto perché la sua pagina di accesso al sito Web della società non ha convalidato correttamente le password?
Quando è stata l'ultima volta che un regolatore / auditor qualificato di un'organizzazione professionale ha dovuto approvare e firmare un sistema di computer pubblico prima che potesse essere messo in uso?
Penseresti che "la gente morirà" sarebbe una buona ragione per costruire edifici con materiali ignifughi, allarmi e buone vie di fuga. Non era . Abbiamo introdotto la normativa per forzare materiali da costruzione non infiammabili, progetti antincendio con interruzioni di incendio, allarmi antincendio.
Potresti pensare che "la gente morirà" sarebbe una buona ragione per far sì che ognuno si preoccupi di costruire la progettazione strutturale. Non è . Semplicemente non è . Dobbiamo avere delle regole per fare in modo che gli ingegneri qualificati firmino progetti di costruzione, che siano progettati e costruiti per usi specifici, e quando le cose vanno male, la società porta gli ingegneri in tribunale .
Penseresti che "la gente morirà" sarebbe una buona ragione per rendere il processo alimentare pulito e sicuro, ma non lo era t .
SQL Injection è meno ovvio, meno visibile pubblicamente e ha un impatto meno severo, ed è in un settore completamente non regolamentato.
Anche per le aziende che si preoccupano di questo, non possono pubblicizzare in modo utile " Nessuna vulnerabilità di SQL injection nota nel nostro codice " come un punto elenco di marketing che interessa a tutti. Non è il tipo di domanda che i clienti chiedono ai venditori. Non è un vantaggio competitivo per loro, è un costo, un sovraccarico. La protezione contro di essa li rende meno competitivi, più lenti in movimento, facendo più lavoro per la stessa funzionalità.
Gli incentivi sono tutti allineati per mantenere l'esistente. Quindi continua a esistere.
Crea un'iniezione SQL un problema per le aziende e la faranno andare via.
[Modifica: esiste un regolamento UE secondo cui i siti Web devono avvisarti se utilizzano i cookie. E lo fanno. Quindi la regolamentazione dei sistemi informatici pubblici per renderli più noiosi può entrare in vigore - anche se il regolamento attuale è piuttosto inutile.
L'iniezione SQL è ancora in circolazione perché il mondo del software continua a non capire che la generazione programmatica di valori strutturati ad albero (come query o markup) dovrebbe essere eseguita costruendo alberi di sintassi come oggetti di prima classe , non concatenando stringhe che rappresentano frammenti di un linguaggio.
Negli ultimi anni c'è stato un po 'di progresso con la crescente disponibilità di strumenti di query builder come LINQ a SQL o SQLAlchemy , ma questo è dal lato del linguaggio di programmazione. I database relazionali non offrono ancora un'interfaccia alternativa standard e convincente che non sia basata fondamentalmente sull'invio di query come stringhe.
Le istruzioni preparate con i parametri di query sono appena un miglioramento, perché sono facili da usare solo se la struttura delle tue query - quali tabelle sono unite, quali condizioni di filtro, quali colonne progettare - è fissi . Quando si dispone di un'applicazione che ha bisogno di costruire testo di query in fase di esecuzione, i parametri di query preparati sono un grosso problema da usare.
Quindi, se un protocollo standardizzato, non testuale e strutturato ad albero può essere costruito per descrivere e comunicare query al database ed è stato progettato per essere più facile da usare rispetto alle query testuali, allora questo risolverebbe il problema nel lungo termine. Ma il problema non andrà via finché l'industria non adotterà qualcosa in cui il percorso di minor resistenza è sicuro. Finché insistiamo su sistemi non sicuri per impostazione predefinita in cui scrivere codice sicuro richiede uno sforzo inutile, i problemi saranno con noi. (Pensa a tutti i buffer overflow che non esistono affatto in linguaggi gestiti dalla memoria!)
Si noti che lo stesso problema fondamentale di SQL injection affligge il Web, sotto il nome di scripting cross-site , che è in realtà solo l'iniezione di Javascript in pagine HTML dinamiche. Un modello molto comune sono i programmatori Javascript che, invece di lavorare con il DOM trattandolo come un albero di oggetti, ricorrono a la proprietà innerHTML per impostarla su un testo HTML creato da una concatenazione di stringhe naïve. Un sacco di vulnerabilità XSS sarebbero mai esistite se la proprietà innerHTML non fosse mai stata inserita nelle implementazioni DOM dei browser.
Inoltre, per le persone che non hanno visto i discorsi di Tony Hoare sui puntatori nulli, è simultaneamente ortogonale (puntatori nulli, non SQL injection) ma allo stesso tempo incredibilmente rilevante:
Durante i test, è molto facile testare ciò che ti aspetti . Ad esempio, quando si compila un campo "nome" in un database, probabilmente sceglierai qualcosa che ti è familiare, come "John Doe". Funziona e l'applicazione sembra funzionare correttamente.
Quindi, un giorno, qualcuno nomina il proprio figlio Robert'); DROP TABLE Students; -- (piccole tabelle di Bobby).
Ovviamente,nontesterailatuaapppernomidelgenere,quindiilbucodisicurezzachetalenomeesponesfuggeatuttiituoitest.
C'èuncommentointeressantequi:
È facile dimostrare che esiste un buco di sicurezza (basta testare un nome come sopra). È anche facile dimostrare che è stato risolto un particolare buco. È difficile dimostrare che non esistano altri buchi di sicurezza.
Steffen ha buoni punti nella sua risposta, ma mi piacerebbe aggiungerlo. Il perché, penso, può essere suddiviso nei seguenti argomenti:
Quindi rompiamoli.
Al giorno d'oggi c'è molta enfasi sulla formazione degli utenti. Insegna agli utenti come mantenere password complesse. Insegna agli utenti come identificare il phishing. Insegna agli utenti come ... Hai avuto l'idea. Alcune imprese, molto probabilmente, ma posso solo parlare con la mia esperienza professionale e non ho lavorato in molte aziende;), ho programmi di formazione. Ma quei programmi di formazione possono essere incompleti o non raggiungere la profondità delle conoscenze necessarie. Ciò non significa screditare il duro lavoro svolto nella realizzazione di quei programmi. Ma per dire che, proprio come nell'ambiente scolastico, diverse persone imparano in modo diverso. E a meno che tu non abbia un programma di formazione continua per gli sviluppatori, sarà difficile comunicare "usa query parametrizzate, ed ecco come farlo in PHP, Java, Python, Ruby, Scala, NodeJS, ...". È un duro lavoro sviluppare, offrire e mantenere programmi di sviluppo che raggiungono effettivamente il pubblico.
In alto, una delle cose a cui alludo era raggiungere il pubblico in modo efficace per diversi tipi di apprendimento. Uno dei motivi è che molte aziende hanno un alto tasso di abbandono per gli sviluppatori, perché gli sviluppatori sono appaltatori che vengono trasferiti da un progetto all'altro in diverse aziende. E le aziende non hanno sempre la stessa maturità di sicurezza. Una società potrebbe non avere un programma di sicurezza, mentre un'altra potrebbe avere un eccellente programma di sicurezza e lo sviluppatore viene improvvisamente bombardato da nuove informazioni che saranno loro richieste per tutti e sei mesi prima di trasferirsi in un'altra azienda. È triste, ma succede.
Consegna del progetto nei tempi previsti o addirittura in anticipo rispetto alla pianificazione. Il percorso più veloce per completare il progetto solitamente, purtroppo, non sta completando il progetto con i controlli di sicurezza. Lo sta facendo nel modo più rotto che funzioni ancora. Sappiamo che più tardi, quando arriverà il momento di mantenere il progetto e risolvere i problemi, causerà più lavoro, più tempo e più denaro, ma la gestione vuole solo il progetto.
Un altro elemento che ho toccato sta sviluppando programmi di formazione sulla sicurezza per una miriade di linguaggi di programmazione. Molte aziende non hanno una o due lingue impostate. Quindi gli sviluppatori amano (o sono incoraggiati) provare la nuova hotness. Ciò include le lingue e le strutture. Ciò significa che i programmi di sicurezza devono evolversi continuamente.
E qui siamo a gestione. Ogni volta, sembra che ci sia stata una violazione pubblica, c'erano controlli che avrebbero potuto essere implementati, che non sono poi così difficili, ma che sono stati persi. Spinge a consegnare i prodotti prima e preoccuparsi secondo sempre, nonostante le lezioni dopo le lezioni dopo le lezioni, ritorna sulle aziende di prodotto. La direzione deve spingere dall'alto per prendersi il tempo di costruire in sicurezza all'inizio. Devono capire che più lavoro, più tempo e più soldi saranno spesi per risolvere problemi, mantenere il prodotto e pagare multe. Ma le analisi costi-benefici indicano il problema della consegna del prodotto, non delle multe o dei lavori di manutenzione richiesti. Queste equazioni devono cambiare, e questo viene, in parte, all'istruzione (wooo, full circle) a livello di MBA. Ai dirigenti aziendali deve essere insegnato che per avere successo in un contesto di violazioni sempre maggiori, la sicurezza deve essere al centro dell'attenzione.
Il perché, nonostante SQLi abbia quasi 20 anni, è pieno di molte ragioni. Come operatori della sicurezza, possiamo fare molto per educare e aumentare la consapevolezza di ciò che accade quando la sicurezza non è considerata parte integrante del SDLC.
Sono d'accordo con molte delle risposte, ma un punto molto importante non è stato fatto: il codice non si risolve magicamente da solo, e c'è molto codice là fuori che ha 17 anni. Ho visto molte aziende scrivere un nuovo codice pulito e sicuro, mentre l'applicazione potrebbe ancora essere attaccata in alcune delle sezioni più vecchie. E peggio di tutto: la fissazione del vecchio codice è costosa, perché richiede agli sviluppatori di approfondire il codice che è stato scritto in un'epoca diversa con stili di codifica e tecnologie differenti. A volte la correzione del vecchio codice per non causare iniezioni SQL richiede di ricreare intere librerie che sono state riacquistate durante il giorno (questo è qualcosa che dovevo fare un paio di anni fa).
Non dire che il tutto nuovo codice è privo di iniezioni SQL, ma personalmente non ho visto alcun nuovo codice scritto professionalmente negli ultimi 4 o 5 anni che li conteneva. (L'unica eccezione è quella in cui gli sviluppatori devono eseguire una correzione rapida e sporca nel vecchio codice e utilizzare lo stesso stile / tecnologia in cui è scritto il resto del codice.)
Credo che sia perché molti sviluppatori apprendono quanto basta per portare a termine il lavoro, per un certo valore di "fatto". Imparano come creare codice SQL, spesso da tutorial online obsoleti, e poi quando il codice "funziona" nella misura in cui possono dire "Posso inserire elementi nel database e posso generare la pagina dei risultati", quindi sono soddisfatto.
Considera questo ragazzo sulla scala:
Perché lo sta facendo? Perché non ha un'armatura adeguata? Perché sta facendo il lavoro. Metti la scala contro il muro sopra le scale, e funziona bene. Fino a quando non lo fa.
Stessa cosa con INSERT INTO users VALUES($_POST['user']) . Funziona bene. Fino a quando non lo fa.
L'altra cosa è che non sono consapevoli dei pericoli. Con il ragazzo sulla scala instabile, comprendiamo la gravità e la caduta. Con la creazione di istruzioni SQL da dati esterni non convalidati, non sanno cosa può essere fatto.
Ho parlato con un gruppo di sviluppatori web lo scorso mese, e dei 15 sviluppatori del pubblico, due avevano sentito parlare di SQL injection.
Penso che la ragione principale sia che la formazione degli sviluppatori non inizia con le migliori pratiche, inizia con la comprensione del linguaggio. Pertanto, i nuovi programmatori, credendo di essere stati addestrati con gli strumenti per creare qualcosa, procedono a creare le domande nel modo in cui sono state insegnate. Il passo successivo e più pericoloso è quello di consentire a qualcuno di sviluppare qualsiasi cosa senza revisione e quindi l'opportunità continua di fare scelte più povere senza sapere che c'è qualcosa di sbagliato in essa e produrre ulteriori abitudini che ignorano le migliori pratiche accettate a livello di settore. Quindi, per riassumere: programmatori mal formati che operano in un ambiente che non valorizza altro che il prodotto finale.
Non ha nulla a che fare con l'intelligenza o la "stupidità umana". C'è un approccio sistematico che è stato ben definito nel corso degli anni ed è negligente per chiunque produca software per ignorare quel processo in nome di un'implementazione più veloce o meno costosa. Forse un giorno le implicazioni legali di questo comportamento ci permetteranno di avere più controlli sul posto, come le industrie mediche o delle costruzioni, in cui il mancato rispetto di queste regole e le pratiche accettate comporteranno una perdita di licenza o altra penalità.
Perché le vulnerabilità di SQL injection non si sono ancora estinte? Metaforicamente parlando, per la stessa ragione per cui gli incidenti automobilistici sono ancora in circolazione dalla prima auto in 1895 e anche il più Le auto innovative e moderne autovetture oggi, Tesla model S ( sull'autopilota) o auto auto-guida di Google si arresta di tanto in tanto tempo.
Le macchine sono create (e controllate) dagli umani, gli umani commettono errori.
I siti Web e le applicazioni (web) sono costruiti da programmatori umani. Tendono a commettere errori nella progettazione della sicurezza o tendono a rompere le cose con "soluzioni rapide" quando qualcosa era sicuro, ma in realtà introduceva una nuova vulnerabilità, ad esempio perché il tempo / budget per lo sviluppo di una correzione era limitato, o lo sviluppatore ha avuto una grande sbornia quando ha scritto la correzione .
È sempre causato dagli sviluppatori? Sostanzialmente sì, ma non sempre dallo sviluppatore di prima linea . Ad esempio, un supermercato locale ha chiesto a una società di sviluppo web di creare un sito Web per loro. Gli sviluppatori noleggiano alcuni spazi di hosting condiviso da una società di hosting per ospitare il sito e installano WordPress e alcuni plugin utili.
Ora gli sviluppatori della società di sviluppo web non devono necessariamente commettere errori per introdurre una vulnerabilità di SQL injection al fine di essere vulnerabili. Cosa potrebbe andare storto qui? Alcuni esempi:
Ora la domanda che viene sollevata , chi è il responsabile? Il supermercato, la società di sviluppo web, la società di hosting, la comunità di WordPress, gli sviluppatori di plugin di WordPress o l'hacker che ha sfruttato la vulnerabilità, retoricamente parlando? - Questa non è una dichiarazione, è esagerata e solo alcune domande che sono suscettibili di essere chiesti nel caso qualcosa vada storto.
Spesso la discussione di cui sopra (domande sulla responsabilità, anche se leggermente esagerate) sono anche un fattore di rischio dal momento che alcuni sviluppatori tendono ad avere un "che non è il mio codice" -attitudine . Puoi immaginare quanto sia complicato a volte rendere la situazione.
Innanzitutto nessuno scrive correttamente i requisiti di sicurezza, dicono qualcosa come "Il prodotto deve essere sicuro" Che in nessun modo è testabile
In secondo luogo, gli sviluppatori di professioni non sono stupidi, e dire che è piuttosto ingenuo, sono tutti probabilmente laureati e hanno risolto problemi che non abbiamo nemmeno iniziato a guardare fuori ... Il problema è che hanno non è mai stato insegnato a cosa serve sviluppare software in modo sicuro. Questo inizia alle scuole, poi all'università e poi a qualsiasi lavoro svolti, dove ogni formazione è "on-the-job" perché le aziende di software sono troppo spaventate per formare gli sviluppatori nel caso in cui se ne vadano.
Gli sviluppatori sono anche sotto pressione crescente per fare più lavoro in meno tempo, sono impegnati a risolvere un problema e passare a quello successivo, c'è poco tempo per riflettere sul prossimo problema.
Gli sviluppatori non sono incentivati a testare oltre ciò che stanno sviluppando, se trovano un problema, sono probabilmente lo sviluppatore a risolverlo. Il mantra dello sviluppatore qui è "Non testare ciò che non sei preparato a risolvere"
In terzo luogo, i tester non sono addestrati a trovare vulnerabilità di sicurezza, per lo stesso motivo degli sviluppatori di software. In effetti una grande quantità di test (a mio parere) sta semplicemente ripetendo i test del team di sviluppo.
Occasionalmente, il time to market è un fattore enorme , se sei là fuori per prima cosa stai facendo soldi, lo sviluppo in sicurezza è visto come un grande impatto sulla velocità di sviluppo - Intendo davvero, chi ha tempo per un modello di minaccia! ;)
Finalmente non sono solo le iniezioni SQL, sono noti gli overflow del buffer sin dagli anni '60 e puoi ancora inciampare su di essi con regolarità allarmante.
Sì, antropologicamente, gli umani sono stupidi .
Sì, politicamente, la struttura degli incentivi non penalizza sufficientemente le applicazioni vulnerabili
Sì, il processo è difettoso - il codice è scritto in fretta; codice cattivo / vecchio è non sempre gettato via .
E, sì, tecnicamente, trattare e mixare i dati come codice è più difficile da fare per impostazione predefinita .
Ma c'è una visione più positiva (ignoriamo il 99% delle vulnerabilità di SQLi che spiegano le risposte sopra). SQLi esiste ancora su siti Web estremamente ben progettati e sviluppati con cura perché siamo fantastici . Regola degli hacker. Hai solo bisogno di guardare le centinaia di vettori di attacco e migliaia di payload SQLi che sono stati sviluppati negli ultimi diciassette anni per riconquistare una certa fiducia nella razza umana. Ogni anno porta con sé nuove tecniche presentate DEFCON / BlackHat / RSA / IEEESSP. Programmi di bounty di bug per Facebook, Google e simili hanno dovuto tutti sborsare almeno una volta per un SQLi critico.
In parte, è a causa della complessità e del numero di livelli nel nostro sistema, ognuno dei dati mutanti in modi più nuovi e più interessanti. Abbiamo sempre più bisogno di più, più velocemente, usando meno risorse. E fintanto che non possiamo testare tutti i percorsi nel sistema, nessuno sta per certificare una soluzione ai problemi di iniezione .
Perché tali problemi di sicurezza non sono coperti durante la maggior parte dei cicli di istruzione di 3 anni e studi equivalenti, e molti sviluppatori hanno seguito tale traccia (incluso me stesso). Considerato l'ampiezza del campo, in realtà 3 anni non sono nemmeno sufficienti per far fronte al programma di studio reale. Quindi, le cose come la sicurezza sono state eliminate.
È spiacevole, ma dal momento che alcuni dei nuovi sviluppatori non cercheranno mai di imparare cose nuove da soli, queste persone scriveranno sempre codice SQLi-prono fino a quando un collega più istruito non indicherà il problema (o fino a quando non sarà un vero SQLi succede).
Durante i miei studi (molti anni fa), i nostri insegnanti ci hanno sempre detto di utilizzare PreparedStatements durante la creazione di query SQL manuali, perché sono "best-practice", ma non hanno detto perché. Questo è meglio di niente, ma piuttosto triste, ancora. Non sono sicuro che quegli insegnanti conoscessero se stessi.
Abbiamo imparato come visualizzare elementi su un jsp, ma non quello che è Cross-Site-Scripting ..
Sono "fortunato" di essere uno sviluppatore appassionato con un po 'di tempo nelle mie mani, quindi ho imparato tutte queste cose da solo molto tempo fa, ma sono sicuro che molti sviluppatori fanno solo le loro 8 ore-a- giorno (per motivi legittimi, a proposito), e fino a quando nessuno mostra loro ciò che è sbagliato, non cambierà.
Se si utilizzano correttamente istruzioni preparate, l'iniezione SQL non è possibile.
"Se il modello dell'istruzione originale non deriva da input esterno, SQL injection non può verificarsi."
Sfortunatamente le persone di solito non usano le istruzioni preparate correttamente, se non del tutto.
L'iniezione SQL sarebbe una cosa del passato, se lo facessero.
E sì, php / MySQL hanno avuto un'implementazione di istruzioni preparata per un tempo molto lungo, oltre 10 anni se la memoria serve ...
Le altre risposte hanno indicato quasi tutte le ragioni. Ma c'è qualcos'altro, che penso sia la preoccupazione per la sicurezza più pericolosa di tutti. Gli sviluppatori cercano di aggiungere sempre più funzionalità alle tecnologie e talvolta si discostano dal vero scopo della tecnologia. Un po 'come un linguaggio di scripting lato client finito per essere utilizzato per la codifica lato server o è stato consentito l'accesso alle risorse remote e all'archiviazione locale lato client. Invece di sovrapporre questi come tecnologie separate, sono stati tutti messi in un unico grande honeypot. Esaminando alcune delle iniezioni SQL avanzate, possiamo vedere come hanno svolto un ruolo nel costante accento degli attacchi SQLi.
Con SQL però, immagino che il più grande errore sia stato l'accoppiamento di comandi e parametri. È un po 'come chiamare run(value, printf) anziché printf(value) .
Oh e un'ultima cosa, anche se è abbastanza facile convertire tra diversi tipi di database, le modifiche richieste nel codice lato server sono enormi.
Qualcuno dovrebbe astrarre tra diversi tipi di database e rendere più facile il passaggio da diversi dbs. Pronuncia un plug-in php che accetta come comandi QL di input e il tipo di database e potrebbe essere un filtro autorizzato per disinfettare l'input.
Personalmente ritengo che questo sia un caso specifico di un problema più generale nella programmazione, che IDE e lingue siano eccessivamente permissivi. Diamo ai nostri sviluppatori un potere immenso in nome della flessibilità e dell'efficienza. Il risultato è "ciò che può succedere accadrà" e le interruzioni della sicurezza sono inevitabili.
PDO (o altri metodi "sicuri") non è più sicuro di mysql_ (o di altri metodi "non sicuri"). Semplifica la scrittura di codice sicuro, ma è ancora più semplice concatenare semplicemente le stringhe fornite dall'utente senza escape nella query e non preoccuparsi dei parametri.
Leggi altre domande sui tag sql-injection web-application data-leakage