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 (specialmente l'associazione di parametri) ma è ancora necessario utilizzare queste tecniche. E molti sviluppatori semplicemente non sono consapevoli dei problemi di sicurezza. La maggior parte si preoccupa che l'applicazione funzioni e non si preoccupa molto della sicurezza, soprattutto se rende le cose (anche leggermente) più complesse e comporta costi aggiuntivi come i test.

Questo tipo di problema non è limitato a SQLi ma lo troverai con buffer overflow, controllo dei certificati, XSS, CSRF .... È più costoso eseguire una programmazione sicura a causa dei test aggiuntivi e dell'esperienza aggiuntiva necessaria allo 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 fin dalla progettazione aiuta molto a renderlo migliore, gli sviluppatori spesso lavorano intorno a questo progetto perché non lo capiscono ed è solo a modo loro.

Perché non è un problema.

• Quando è stata l'ultima volta che un'azienda con una vulnerabilità di SQL injection è stata trattenuta in tribunale e punita con una multa per essere stata avventata con dati degli utenti e gli amministratori hanno ammonito, multato o rinchiuso per negligenza?

• Quando è stata l'ultima volta che un'azienda ha perso un grosso contratto perché la pagina di accesso al sito web della sua azienda non ha convalidare correttamente le password?

• Quando è stata l'ultima volta che un regolatore / revisore qualificato di un'organizzazione professionale ha dovuto approvare e firmare un sistema informatico per il pubblico prima che potesse essere utilizzato ?

Penseresti che "la gente morirà" sarebbe una ragione sufficiente per costruire edifici con materiali ignifughi, allarmi e buone vie di fuga. Non lo era. Abbiamo introdotto un regolamento per imporre materiali da costruzione non infiammabili, progetti antincendio con interruttori antincendio, allarmi antincendio.

Potresti pensare che "le persone moriranno" sarebbe una ragione sufficiente per convincere tutti cura della progettazione strutturale degli edifici. Non lo è. Semplicemente non lo è. Dobbiamo avere una regolamentazione per far sì che ingegneri qualificati firmino i progetti di edifici, che siano progettati e costruiti per usi specifici e, quando le cose falliscono, la società porta gli ingegneri in tribunale.

Potresti pensare che "le persone moriranno" sarebbe una ragione sufficiente per rendere la lavorazione del cibo pulita e sicura, ma non lo era.

SQL Injection è meno ovvio, meno visibile pubblicamente e ha un impatto di minore gravità ed è in un settore completamente non regolamentato.

Anche le aziende a cui interessa, non possono pubblicizzare utilmente " Nessuna vulnerabilità nota di SQL injection nel nostro codice " come punto di marketing a cui interessa chiunque. Non è il tipo di domanda che i clienti fanno ai venditori. Non è un vantaggio competitivo per loro, è un costo, un sovraccarico. Proteggersi li rende meno competitivi, si muovono più lentamente e lavorano di più per la stessa funzionalità.

Gli incentivi sono tutti allineati affinché continui a esistere. Quindi continua a esistere.

Rendi SQL injection un problema per le aziende e loro lo faranno scomparire.

[Modifica: ma c'è un regolamento UE che i siti web devono avvisarti se usano i cookie. E lo fanno. Quindi la regolamentazione dei sistemi informatici rivolti al pubblico per renderli più fastidiosi può entrare in vigore, anche se l'attuale regolamento è piuttosto inutile.]

SQL injection è ancora in circolazione perché il mondo del software non comprende ancora 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 sono stati compiuti alcuni progressi con la crescente disponibilità di strumenti di creazione di query come LINQ to 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 fondamentalmente basata sull'invio di query come stringhe.

Le istruzioni preparate con parametri di query sono a malapena un miglioramento, perché sono facili da usare solo se il La struttura delle tue query, quali tabelle sono unite, quali condizioni di filtro, quali colonne proiettare, è fissa . Quando si dispone di un'applicazione che deve creare testo di query in fase di esecuzione, i parametri di query preparati sono un grosso problema da usare.

Quindi, se fosse possibile costruire un protocollo standardizzato, non testuale e strutturato ad albero per descrivere e comunicare le query al database, ed è stato progettato per essere più facile da usare rispetto alle query testuali, allora questo risolverebbe il problema problema a lungo termine. Ma il problema non scomparirà 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 non necessario, i problemi saranno con noi. (Pensa a tutti i buffer overflow che non esistono affatto nei linguaggi con gestione della memoria!)

Tieni presente che lo stesso problema fondamentale dell'SQL injection affligge il Web, sotto il nome di cross-site scripting , 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 alla proprietà innerHTML per impostarla su testo HTML che è costruito da ingenua concatenazione di stringhe. Molte vulnerabilità XSS non 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 il discorso di Tony Hoare sui puntatori nulli, è simultaneamente ortogonale (puntatori nulli, non iniezione SQL) ma allo stesso tempo incredibilmente rilevante:

• Tony Hoare, "Null References: The Billion Dollar Mistake".

Durante il test, è molto facile verificare ciò che ti aspetti che accada. Ad esempio, quando compili un campo "nome" in un database, probabilmente sceglierai qualcosa che conosci, come "John Doe". Funziona e la tua applicazione sembra funzionare bene.

Poi, un giorno, qualcuno chiama il proprio figlio Robert '); DROP TABLE Studenti; - (piccoli Bobby Tables).

Ovviamente non testerai la tua app per nomi del genere , quindi il buco di sicurezza esposto da un tale nome sfugge a tutti i tuoi test.

C'è un commento interessante qui: L'immalsificabilità delle dichiarazioni di sicurezza

È facile provare l'esistenza di una falla di sicurezza (devi solo testare un nome come quello sopra). È anche facile dimostrare che un particolare buco è stato risolto. È difficile dimostrare che non esistono altri buchi di sicurezza.

Steffen fa buoni punti nella sua risposta, ma vorrei aggiungere qualcosa. Il perché, penso, può essere suddiviso nei seguenti argomenti:

• Mancanza di conoscenza o formazione degli sviluppatori
• Abbandono in un ambiente di sviluppo aziendale
• Pressione per fornire in anticipo sulla pianificazione
• Poca enfasi dall'alto sulla sicurezza

Quindi analizziamoli.

Formazione per sviluppatori

Oggigiorno si dà molta importanza all'istruzione degli utenti. Insegna agli utenti come mantenere password complesse. Insegna agli utenti come identificare il phishing. Insegna agli utenti come ... Hai capito. Alcune imprese, molto probabilmente, ma posso solo parlare della mia esperienza professionale e non ho lavorato in molte imprese;), hanno programmi di formazione. Ma questi programmi di formazione possono essere incompleti o non raggiungere la profondità di conoscenza necessaria. Questo non è per screditare il duro lavoro che richiede la creazione di quei programmi. Ma per dire che proprio come nell'ambiente scolastico, persone diverse imparano in modo diverso. E a meno che tu non abbia un programma di formazione continua per sviluppatori, sarà difficile comunicare "usa query parametrizzate, ed ecco come farlo in PHP, Java, Python, Ruby, Scala, NodeJS, ...". È un duro lavoro sviluppare, fornire e mantenere programmi per sviluppatori che raggiungano efficacemente il pubblico.

Abbandono degli sviluppatori

Sopra, una delle cose a cui ho accennato 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 spostati da un progetto all'altro in società diverse. E le aziende non hanno sempre la stessa maturità di sicurezza. Una società potrebbe non avere affatto 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 richieste per tutti i sei mesi prima di trasferirsi in un'altra società. È triste, ma succede.

Consegna del progetto

Consegna del progetto nei tempi previsti o addirittura in anticipo. Il percorso più rapido per completare il progetto di solito, purtroppo, non è completare il progetto con i controlli di sicurezza. Lo sta facendo nel modo più rotto che funziona ancora. Sappiamo che ciò causerà più lavoro, più tempo e più denaro in seguito quando arriverà il momento di mantenere il progetto e risolvere i problemi, ma la direzione vuole solo che il progetto venga risolto.

Un altro elemento che ho toccato è sviluppare programmi di formazione sulla sicurezza per una miriade di linguaggi di programmazione. Molte aziende non hanno una o due lingue impostate. Quindi agli sviluppatori piace (o sono incoraggiati) provare il nuovo hotness. Ciò include linguaggi e framework. Ciò significa che i programmi di sicurezza devono evolversi continuamente.

Comprensione della gestione

E qui siamo alla direzione. Ogni volta, sembra come in una violazione pubblica, c'erano controlli che avrebbero potuto essere implementati, che non sono così difficili, ma sono stati persi. Spinge a consegnare prima i prodotti e poi a preoccuparsi sempre, nonostante lezione dopo lezione dopo lezione, ritorna sulle aziende produttrici. La direzione deve spingere dall'alto per prendere il tempo necessario per costruire la 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 che il problema è la consegna del prodotto, non le multe o i lavori di manutenzione richiesti. Quelle equazioni devono cambiare, e questo arriva, in parte, all'istruzione (wooo, cerchio completo) a livello di MBA. Ai manager aziendali deve essere insegnato che per avere successo in un panorama di violazioni in costante aumento, la sicurezza deve essere al centro e al centro.

Conclusione

Il perché, nonostante SQLi abbia quasi 20 anni , è irto di diversi motivi. In qualità di professionisti della sicurezza, possiamo solo fare molto per educare e aumentare la consapevolezza di ciò che accade quando la sicurezza non è considerata parte integrante dell'SDLC.

Sono d'accordo con molte delle risposte, ma non è stato fatto un punto molto importante: il codice non si aggiusta magicamente da solo, e c'è molto codice là fuori che ha 17 anni. Ho visto molte aziende scrivere nuovo codice pulito e sicuro, mentre l'applicazione potrebbe ancora essere attaccata in alcune delle sue sezioni più vecchie. E la cosa peggiore: riparare il vecchio codice è costoso, perché richiede agli sviluppatori di approfondire il codice che è stato scritto in un'epoca diversa con diversi stili di codifica e diverse tecnologie. A volte riparare il vecchio codice per non causare SQL injection richiede di ricreare intere librerie che sono state acquistate nel corso della giornata (questo è qualcosa che ho dovuto fare un paio di anni fa).

Per non dire che tutto il nuovo codice è privo di SQL injection, ma personalmente non ho visto alcun nuovo codice scritto professionalmente negli ultimi 4 o 5 anni che li contenesse. (L'unica eccezione è quando gli sviluppatori devono eseguire una correzione rapida e sporca del vecchio codice e utilizzare lo stesso stile / tecnologia in cui è scritto il resto del codice.)

Credo che sia perché molti sviluppatori imparano quel tanto che basta per portare a termine il lavoro, per un certo valore di "fatto". Imparano a costruire codice SQL, spesso da tutorial online obsoleti, e poi quando il codice "funziona" nella misura in cui possono dire "Posso mettere cose nel database e posso generare la pagina dei risultati", allora sei soddisfatto.

Considera questo ragazzo sulla scala:

Perché lo fa? Perché non ha un'impalcatura adeguata? Perché sta portando a termine il lavoro. Metti la scala contro il muro sopra le scale e funziona perfettamente. Fino a quando non lo fa.

Stessa cosa con INSERT INTO users VALUES ($ _ POST ['user']) . Funziona benissimo. 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 si può fare.

Ho parlato con un gruppo di utenti di sviluppatori web il mese scorso e dei 15 sviluppatori del pubblico, due avevano sentito di SQL injection.

Penso che il motivo principale sia che la formazione per 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 query nel modo in cui sono stati insegnati. Il passo successivo e più pericoloso è consentire a qualcuno di sviluppare qualsiasi cosa senza revisione e quindi continua opportunità di fare scelte più sbagliate senza sapere che c'è qualcosa di sbagliato in esso e produrre ulteriori abitudini che ignorano le migliori pratiche accettate a livello di settore. Quindi, per riassumere: programmatori poco preparati che operano in un ambiente che non apprezza nient'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 ignorare quel processo in nome di un'implementazione più rapida o meno costosa. Forse un giorno le ramificazioni legali di questo comportamento ci consentiranno di avere più controlli in atto come il settore medico o edile, dove il mancato rispetto di queste regole e pratiche accettate comporterà la perdita della licenza o altre sanzioni.

Perché le vulnerabilità di SQL injection non si sono ancora estinte? Metaforicamente parlando, per lo stesso motivo per cui gli incidenti automobilistici sono ancora in circolazione sin dalla prima auto nel 1895 e persino le auto a guida autonoma più innovative e moderne di oggi, Tesla modello S (con il pilota automatico) o auto a guida autonoma di Google di tanto in tanto.

Le auto sono create (e controllate) da umani, gli umani commettono errori.

I siti web e le applicazioni (web) sono costruiti da programmatori umani. Tendono a commettere errori scadenti nella progettazione della sicurezza o tendono a rompere le cose con "correzioni rapide e sporche" quando qualcosa era sicuro, ma in realtà introduce 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? Essenzialmente 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 affittano uno spazio 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 un errore nell'introdurre una vulnerabilità di SQL injection per essere vulnerabili. Cosa potrebbe andare storto qui? Alcuni esempi:

1. La società di hosting non si è aggiornata all'ultima versione di PHP e le versioni PHP utilizzate si sono rivelate vulnerabili a SQLi in generale.
2. L'hosting l'azienda ha configurato alcuni software aggiuntivi pubblici come phpMyAdmin e non l'ha aggiornato.
3. La versione di WordPress utilizzata risulta essere vulnerabile a SQLi ma l'aggiornamento è stato mancato o non è ancora disponibile la patch.
4. Un plug-in di WordPress utilizzato è vulnerabile a SQLi.

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 per WordPress o l'autore dell'attacco che ha abusato della vulnerabilità, retoricamente parlando? - Questa non è un'affermazione, è esagerata e solo alcune domande che è probabile che venga chiesto nel caso qualcosa vada storto.

Spesso la discussione di cui sopra (domande sulla responsabilità, sebbene leggermente esagerate) sono anche un fattore di rischio poiché alcuni sviluppatori tendono ad avere un "non mio codice "-attitude . Puoi immaginare quanto sia complicato a volte la situazione.

In primo luogo nessuno scrive correttamente i requisiti di sicurezza, dicono qualcosa del tipo "Il prodotto deve essere sicuro" che in nessun modo è testabile

In secondo luogo, gli sviluppatori di professionisti non sono stupidi e dirlo è piuttosto falso, è probabile che abbiano tutti titoli universitari e abbiano risolto problemi che non abbiamo nemmeno iniziato a guardare ... Il problema è che non è mai stato insegnato loro cosa significa sviluppare software in modo sicuro. Questo inizia nelle scuole, poi all'università e poi qualunque lavoro intraprendano, dove qualsiasi formazione è "sul lavoro" perché le aziende di software hanno troppa paura di formare gli sviluppatori nel caso in cui se ne vadano.

Gli sviluppatori non sono incentivati ​​a testare oltre a ciò che stanno sviluppando, se trovano un problema, è probabile che siano lo sviluppatore a risolverlo. Il mantra dello sviluppatore qui è "Non testare ciò che non sei disposto a risolvere"

In terzo luogo, i tester sono inoltre non è addestrato a trovare vulnerabilità di sicurezza, più o meno per la stessa ragione degli sviluppatori di software. In effetti, una grande quantità di test (secondo me) consiste semplicemente nel ripetere i test che il team di sviluppo.

mercato è un fattore enorme , se sei là fuori per primo stai facendo soldi, sviluppare in modo sicuro è visto come avere un grande impatto sulla velocità di sviluppo - voglio dire davvero, chi ha tempo per un modello di minaccia! ;)

Infine non si tratta solo di iniezioni SQL, i buffer overflow sono noti dagli anni '60 e puoi ancora inciampare su di essi con allarmante regolarità.

Sì, antropologicamente gli umani sono stupidi.

Sì, politicamente, la struttura degli incentivi non penalizza sufficientemente le applicazioni vulnerabili

Sì, il processo è imperfetto - codice è scritto in fretta; il codice cattivo / vecchio non viene sempre gettato via.

E, sì, tecnicamente trattare e mescolare i dati come codice è più difficile da fare per impostazione predefinita.

Ma c'è una visione più positiva (ignoriamo il 99% delle vulnerabilità SQLi spiegate dalle risposte precedenti). SQLi esiste ancora su siti web estremamente ben progettati e sviluppati con cura perché siamo fantastici . Gli hacker dominano. 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 riguadagnare un po 'di fiducia nella razza umana. Ogni anno porta con sé nuove tecniche presentate DEFCON / BlackHat / RSA / IEEESSP. I programmi di bug bounty per Facebook, Google e simili hanno tutti dovuto sborsare almeno una volta per un SQLi critico.

In parte, è a causa della complessità e del numero di livelli nel nostro sistema, ognuno dei quali muta i dati in modi più nuovi e più interessanti. Abbiamo sempre più bisogno di fare di più, più velocemente, utilizzando meno risorse. E fintanto che non siamo in grado di testare in modo fattibile tutti i percorsi nel sistema, nessuno certificherà una soluzione ai problemi di iniezione.

Perché tali problemi di sicurezza non sono coperti durante la maggior parte dei cicli di istruzione triennale e studi equivalenti, e molti sviluppatori hanno seguito tale percorso (me compreso). Considerando l'ampiezza del campo, in realtà 3 anni non sono nemmeno sufficienti per far fronte al programma di studio vero e proprio. Quindi cose come la sicurezza vengono abbandonate.

È un peccato, ma poiché alcuni dei nuovi sviluppatori hanno vinto Non cercheranno mai di imparare cose nuove da sole, quelle persone scriveranno sempre codice incline a SQLi fino a quando un collega più istruito non indicherà il problema (o fino a quando non si verificherà un vero SQLi).

Durante i miei studi (molti anni fa), i nostri insegnanti ci hanno sempre detto di usare PreparedStatements durante la creazione di query SQL manuali, perché è "best practice", ma non hanno detto perché. Questo è meglio di niente, ma piuttosto triste, comunque. Non sono sicuro che quegli insegnanti conoscessero se stessi.

Abbiamo imparato come visualizzare le cose su un jsp, ma non cos'è Cross-Site-Scripting ..

Sono "fortunato" ad essere uno sviluppatore appassionato con un po 'di tempo nel mio mani, quindi ho imparato tutte queste cose da solo molto tempo fa, ma sono sicuro che molti sviluppatori fanno solo le loro 8 ore al giorno (per motivi legittimi tra l'altro), e finché nessuno mostra loro cosa è sbagliato, non cambierà.

Se utilizzi correttamente le istruzioni preparate, l'iniezione SQL non è possibile.

"Se il modello di istruzione originale non è derivato da un input esterno, l'iniezione SQL non può verificarsi."

https://en.m.wikipedia.org/wiki/ Prepared_statement

Sfortunatamente le persone di solito non usano le istruzioni preparate correttamente, se non del tutto.

L'iniezione SQL sarebbe un ricordo del passato se lo facessero.

E sì, php / MySQL ha implementato una dichiarazione preparata per molto tempo, 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 di sicurezza più pericolosa di tutte. Gli sviluppatori tentano di aggiungere sempre più funzionalità alle tecnologie e talvolta si discostano dallo scopo effettivo della tecnologia. Un po 'come il modo in cui un linguaggio di scripting lato client è stato utilizzato per la codifica lato server o è stato consentito l'accesso a risorse remote e archiviazione locale lato client. Invece di stratificarli come tecnologie separate, sono stati tutti messi in un unico grande honeypot. Esaminando alcune delle iniezioni SQL avanzate, possiamo vedere come hanno giocato un ruolo nell'accento costante degli attacchi SQLi.

Con SQL, però, credo che l'errore più grande sia stato l'accoppiamento di comandi e parametri. È un po 'come chiamare run (value, printf) invece di printf(value).

Oh e un'ultima cosa, mentre è abbastanza facile da 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 passare da un database all'altro. Diciamo un plug-in php che accetta come input i comandi QL e il tipo di database e potrebbe essere un filtro autorizzato per disinfettare l'input.

Personalmente penso che questo sia un caso specifico di un problema più generale nella programmazione, che IDE e linguaggi sono 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 lacune di sicurezza sono inevitabili.

PDO (o altri metodi "sicuri") non è più sicuro di mysql_ (o altri metodi "non sicuri"). Rende più facile scrivere codice sicuro, ma è ancora più semplice concatenare le stringhe fornite dall'utente senza caratteri di escape nella query e non preoccuparsi dei parametri.