Domanda:
SQL injection ha 17 anni. Perché è ancora in giro?
Ishan Mathur
2016-06-27 10:13:09 UTC
view on stackexchange narkive permalink

Non sono un tecnico e vorrei la tua esperienza per capirlo. Recentemente ho letto un articolo dettagliato su SQLi per un documento di ricerca.

Mi sembra strano. Perché continuano a verificarsi così tante violazioni dei dati tramite SQL injection? Non esiste una soluzione?

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/41748/discussion-on-question-by-ishan-mathur-sql-injection-is-17-years-old-why-è).
Sai che la malaria è ancora in circolazione, giusto?e questo in realtà uccide le persone.
Gli exploit di buffer overflow esistono da * oltre 30 anni *, eppure sono ancora una cosa, nonostante il fatto che in realtà non sia così difficile da risolvere per i fornitori.
Chiederei la stessa cosa su SQL.
I clienti non esperti di tecnologia semplicemente non pagheranno per le modifiche al codice finché non vedranno accadere qualcosa di brutto che danneggerà i loro profitti: "Non è nel budget!", "Non vedo il problema, ha funzionato bene negli ultimi 15 anni". Non sanno di essere stati hackerati tramite SQL injection perché non controllano mai i log del server e l'hacker non è mai abbastanza gentile da inviare loro un'e-mail ...
Raccogliere le tasche delle persone è ancora "una cosa" dopo migliaia di anni di pantaloni.
Le cinture di sicurezza esistono da più di 17 anni e alcune persone ancora non le usano.L'iniezione SQL sarà sempre disponibile poiché hai utenti fidati che devono scrivere query dirette.Se si dispone di dati (utente) non attendibili, esistono strumenti affidabili (preparati / parametrizzati) per le query che impediscono al 100% l'iniezione.
A mio parere, dipende dagli utenti (o dagli acquirenti, che è quasi la stessa cosa, nei casi in cui il software viene acquistato).Sono disposti a pagare meno per spazzatura a buon mercato piuttosto che di più per programmi solidi.Questo è molto più grande del solo settore dei computer, ovviamente, ma si riduce al fatto che il tempo extra per prevenire correttamente SQL Injection non vale la pena per l'azienda, e pagano i nostri stipendi.
Il messaggio "Non esiste * correzione *?"la formulazione mi fa sospettare un malinteso: SQLi non è un "bug" che deve essere * corretto. * La domanda potrebbe essere riformulata come, "Perché non è stato sviluppato un modo automatico e infallibile al 100% di bloccare SQLi?"La risposta è che non esiste un modo automatico e infallibile al 100% per distinguere un SQL legittimo da un SQL illegittimo.Solo il progettista di un'applicazione saprà se il testo inviato deve consentire o meno SQL.Quindi spetta al progettista implementare le varie protezioni menzionate nelle altre risposte.
Sedici risposte:
#1
+470
Steffen Ullrich
2016-06-27 10:25:48 UTC
view on stackexchange narkive permalink

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.

Mancanza di consapevolezza e pigrizia ...
"Non esiste una soluzione generale per SQLi perché non esiste una soluzione per la stupidità umana".È una bella citazione!
Esistono correzioni generali per sqli proprio come ci sono correzioni per buffer overflow, implicano il lavoro su costrutti di livello superiore che non consentono che si verifichino.Lavorare con la maggior parte dei linguaggi gestiti risolve gli overflow del buffer, tecnici come linq fix sqli.Sqli sarà presente finché le persone useranno sql direttamente, ma è già andato per coloro che lo desiderano
Non è sempre stupidità umana tu (almeno non da parte dello sviluppatore)!Conosco molte aziende brasiliane che fanno un tatic economico qui: assumono invece di sviluppatori a pieno titolo, assumono un gruppo di apprendisti per evitare le tasse e pagare meno i loro dipendenti.E queste sono grandi aziende!Tali ragazzi non hanno ancora alcuna conoscenza (alcuni di loro sono al loro primo semestre di studi) o anche consapevolezza di tali problemi, e hanno la responsabilità di costruire sistemi che saranno, ovviamente, imperfetti.L'ho visto troppo qui.Potrei anche dare da 5 a 6 nomi.È una cosa davvero triste.
@Malavos: Non intendo necessariamente la stupidità dello sviluppatore.Assumere sviluppatori in base allo stipendio invece che alla conoscenza è stupido.
** I commenti non sono per discussioni estese **;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/41757/discussion-on-answer-by-steffen-ullrich-sql-injection-is-17-years-old-why-è).
"perché non c'è soluzione per la stupidità umana" Allora perché gli umani sono ancora in giro?
@Malavos Condivido il tuo sentimento.Ho perso il conto su quanti sistemi dovevo riparare che erano stati costruiti da "quell'allievo che ha lavorato qui prima".Come un altro sviluppatore brasiliano, posso anche affermare che questo accade ovunque in questo paese!
@Turion, concediti [ancora un po 'di tempo] (https://books.google.com/books?hl=en&lr=&id=gUXgpH6nizIC).Mancano [3 minuti a mezzanotte] (http://thebulletin.org/timeline)
L'iniezione non è un fallimento di una lingua o di una piattaforma;è un fallimento di un programmatore.Non puoi risolvere i problemi delle persone con soluzioni tecnologiche (anche se puoi coprirli, ad esempio le query parametrizzate possono coprire le vulnerabilità di injection).
Penso che il confronto con alcune malattie funzioni nel modo in cui, sebbene sia possibile E frequente ottenere SQLi, ci sono modi ben noti per evitarlo.Non è una vulnerabilità che "ottieni" da un cattivo download e poi il tuo sistema muore.Puoi evitare molte malattie seguendo alcune linee guida, ma le persone si ammalano ancora per non lavarsi le mani o per non cucinare correttamente il cibo.
Finché non c'è fuoco, va bene non rendere la casa ignifuga.
ma .. potrebbe essere risolto non avendo SQL
La stupidità umana è regolata dalla morte.
#2
+280
TessellatingHeckler
2016-06-27 22:10:40 UTC
view on stackexchange narkive permalink

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.]

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/41860/discussion-on-answer-by-tessellatingheckler-sql-injection-is-17-years-old-why-i).
Mi chiedo quando verrà il momento di introdurre una legislazione relativa all'informatica
Attento a ciò che desideri per @prusswan.Negli Stati Uniti, almeno, la stragrande maggioranza delle leggi di regolamentazione tecnologica in atto o tentate sono state messe in atto da lobbisti con poca o nessuna comprensione del quadro generale.
beh, una certa legislazione è meglio di nessuna legislazione
@prusswan Confuto così la tua argomentazione: nessuna legislazione è meglio di una cattiva legislazione.
[Le leggi sulla notifica di violazione della sicurezza] (https://en.wikipedia.org/wiki/Security_breach_notification_laws) sono problemi aziendali.
@prusswan, ci sono leggi.Guarda in HIPPA per esempio.
@prusswan Davvero?Preferiresti avere * qualsiasi * legislazione piuttosto che nessuna legislazione?E se quella legislazione richiedesse che la tua crittografia avesse una backdoor?E se quella legislazione ti obbligasse a usare md5 per tutto l'hashing?E se quella legislazione ti richiedesse di mantenere tutte le password in chiaro, senza hash e senza sale?Sei * assolutamente sicuro * che * una certa legislazione * sia migliore di * nessuna legislazione *?
nessuna legislazione dà l'idea che la professione nel suo insieme sia riluttante ad accettare responsabilità e non possa essere presa più sul serio.Se la legislazione è cattiva, risolverla o, meglio ancora, introdurre una buona legislazione prima che qualcun altro inserisca quella cattiva
HIPAA è legato alla salute, quindi tutto il resto è un gioco leale?
in questo modo: preferiresti scrivere il tuo SQL o lasciare che lo scriva Trump per te?
#3
+119
Luis Casillas
2016-06-27 10:49:40 UTC
view on stackexchange narkive permalink

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:

** I database relazionali non offrono ancora uno standard, ... sull'invio di query come stringhe. ** I database sono accessibili dalle reti, quindi l'API per generare query protette è sempre sul lato dell'applicazione.Inoltre ciò richiederebbe loro di implementare quella soluzione in tutte le lingue.Hanno già implementato driver per comunicare, eseguire transazioni e consentire di eseguire query parametrizzate più facilmente.Non credo che si possa davvero chiedere di più dalla loro parte.
I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (http://chat.stackexchange.com/rooms/41756/discussion-on-answer-by-luis-casillas-sql-injection-is-17-years-old-why-é suo).
Non penso ci sarebbe nulla di sbagliato nell'usare "innerHTML" se fosse limitato alla creazione di oggetti di solo testo anonimi.È molto più pratico poter impostare un campo su "Questo è importante : qualunque" piuttosto che dover creare e inserire un oggetto annidato separato per il testo in grassetto.Sfortunatamente, non conosco alcun meccanismo per creare quel tipo di oggetto aggregato che sarebbe semplicemente incapace di creare tipi di oggetti più "pericolosi".
Non posso votare abbastanza a favore di questa risposta.Lo dico da decenni, è così bello sentire almeno un'altra persona che lo dice.
Per quanto riguarda le vulnerabilità più banali derivanti dall'uso ingenuo della concatenazione di stringhe, sono ancora comuni nel codice scritto da persone che non sanno cosa stanno facendo perché ** le API meno sicure non sono state rimosse **.Se le funzioni dell'interfaccia DB in PHP e in altri linguaggi rimuovessero completamente le API flat-string vecchio stile (rompendo tonnellate di codice esistente), molto codice homebrew scritto da persone che non sanno davvero come programmare sarebbe in qualche modo più sicuro.
L'esistenza di vecchi tutorial che insegnano nel modo sbagliato è anche un grosso problema per cose come PHP, dove molto codice viene copiato e incollato da persone che non lo capiscono.
Sono uno sviluppatore SQL e non sono d'accordo con questo "Quando si dispone di un'applicazione che deve costruire il testo della query in fase di esecuzione, i parametri di query preparati sono un grande problema da usare."Non è più difficile creare query sicure in un programma di quanto non lo sia a mano.
@PeterCordes L'utilizzo delle API più sicure non costringerà le persone a non utilizzare la concatenazione di stringhe.Come sarebbe?Puoi facilmente fare `$ db-> buildQuery (" select * from users where username = '$ username' ") -> execute ()` o simili.
Non sono d'accordo che i parametri siano un problema da usare nella creazione dinamica di query.Non è affatto difficile, una volta che abbiamo dovuto sviluppare la nostra soluzione simile all'ibernazione per un progetto interno e i parametri con cui si occupa una delle parti più facili.
Mi piace molto la sua risposta e sarei davvero interessato a vedere una tale soluzione di albero della sintassi.Tuttavia, come dice Steffen Ullrich, la stupidità umana non conosce limiti, quindi scommetto che ci sarebbero persone che costruiranno questo albero della sintassi concatenando stringhe e quindi utilizzando il ciondolo eval del loro linguaggio preferito per trasformarlo in una struttura dati reale.Quindi avremmo due buchi nella sicurezza dove ce n'era solo uno con cui iniziare.:-(
#4
+58
Nick Gammon
2016-06-27 12:23:35 UTC
view on stackexchange narkive permalink

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).

enter image description here

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.

Sebbene non copra tutte le SQL injection, i test solo utilizzando la semplice citazione in un nome o il carattere cancelletto # coprono una parte piuttosto enorme della vulnerabilità delle applicazioni verso SQL injection.
@Walfrat Peccato che `O'Brien` potrebbe voler aprire un account.
+1 per un'ottima risposta.La mancanza di casi di test adeguati è (IMHO) una ragione migliore della stupidità umana o degli errori.È difficile affermare che qualcosa che è funzionalmente corretto per i casi di test esistenti sia un "errore", e non usare le migliori pratiche non è nemmeno "stupidità", ma piuttosto solo mancanza di conoscenza dell'argomento.Se i casi di test includessero sempre SQL injection, il problema non si presenterebbe altrettanto spesso e le best practice verrebbero molto probabilmente rispettate.
@MichaelKjörling Il nome di O'Brian è * Bobby *?Potrebbe essere un problema ...
@MichaelKjörling Penso che il punto di @Walfrat's fosse che è abbastanza facile eseguire alcuni test per SQLi semplicemente includendo lo strano `` '' nei dati di input del test.Non credo che intendesse promuovere il filtraggio degli apostrofi a livello di applicazione (anche se posso vedere come potresti interpretarlo come tale).
La mia risposta stava davvero cercando di rispondere alla domanda: * perché il problema è ancora presente dopo 17 anni? * Non: * il modo migliore per risolvere l'iniezione SQL. *
Niente come un esempio concreto per spiegare rapidamente e chiaramente un problema.Non posso votare abbastanza QUESTA risposta ...
@MichaelKjörling è in realtà un * motivo in più * per testare che funziona con `` '' nel nome, non uno in meno.(Di recente un negozio online ha rimosso il "+" dal mio indirizzo e-mail. Hanno dovuto inviarmi invece una posta cartacea. Avrebbe dovuto anche essere testato.)
Per quanto riguarda il fumetto XKCD, la sanificazione degli input * non * è la soluzione: rendere l'input al database, * e * qualsiasi elaborazione dei dati all'interno del database, poiché impotente è la soluzione.Per questo vengono utilizzati i parametri SQL e un'attenta considerazione dell'elaborazione (ad esempio SQL dinamico).È necessario anche un atteggiamento simile nei confronti dell'HTML visualizzato.
#5
+29
h4ckNinja
2016-06-27 11:00:32 UTC
view on stackexchange narkive permalink

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.

"Formazione per sviluppatori" ... Giusto ... a volte la gente starebbe meglio senza di essa.Un mio amico ha terminato un corso di Java presumibilmente accreditato (qualunque cosa significhi) in Germania all'inizio di quest'anno.I protagonisti della parte SQL del corso?Concatenazione di stringhe e un metodo chiamato `safe ()` che renderebbe le stringhe "sicure" facendo l'escape delle virgolette e solo le virgolette.In 5 minuti ho trovato 2-3 modi diversi per eseguire SQLi sul codice di esempio fornito dall'insegnante.Chissà cosa farebbero gli strumenti di sondaggio SQLi automatizzati da quella pila di, uh, codice ...
Quindi quei programmi sono gestiti da persone incompetenti.Ma ciò non significa che la formazione per sviluppatori non funzioni.L'ho visto funzionare.Piuttosto che presumere che la formazione per sviluppatori non funzioni, guarda il motivo del suo fallimento.Così giusto ...
Aggiungerei "fornitori di DB che cercano di stipare tutto in una chiamata".Se il modo per eseguire alcuni sql è chiamare sempre una funzione che accetta SQL arbitrario, gli sviluppatori devono fare molto lavoro sulla sicurezza.I fornitori potrebbero facilmente aggiungere una funzione (forse denominata "seleziona"?) Che consente * solo * * una * * selezione * - nessun separatore di istruzioni, nessun commento, nessun "rilascio", nessun "aggiornamento" .... Facile daimplementare, facile da usare, abbastanza sicuro e copre * molto * di ciò di cui hanno bisogno gli utenti (specialmente i principianti), quindi potrebbe ridurre significativamente le superfici di attacco.
@TextGeek L'integrazione tra SQL Server e C # /. NET è davvero fantastica.Sono disponibili diversi strumenti per utilizzare selezioni e aggiornamenti sicuri e qualsiasi altra cosa - tuttavia, _molti_ di sviluppatori semplicemente ignorano quelli e vanno subito alle chiamate non sicure e generiche "basta eseguire questo SQL".
#6
+23
David Mulder
2016-06-28 01:01:45 UTC
view on stackexchange narkive permalink

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.)

#7
+16
Andy Lester
2016-07-07 00:58:08 UTC
view on stackexchange narkive permalink

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:

Guy on a dangerous ladder

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.

#8
+11
Bron Davies
2016-06-27 21:10:18 UTC
view on stackexchange narkive permalink

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.

concordato.google "sql examples" e otterrai molti esempi di espressioni SQL, nessuna delle quali è sicura, perché sono tutte solo stringhe.Se è così che impari a scrivere SQL, allora è quello che utilizzerai nel tuo primo progetto ...
@MarkLakata Questa è anche la mia osservazione.Le nuove persone fanno molto affidamento su Google.Google tende a tirare fuori esempi assolutamente orribili ... Query dinamiche che selezionano * per una colonna da tabelle molto ampie.È sbalorditivo come quegli orribili esempi SQL continuino a galleggiare in cima alle ricerche di Google utilizzate dai nuovi sviluppatori.
#9
+8
Bob Ortiz
2016-06-27 14:15:16 UTC
view on stackexchange narkive permalink

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.

L'uso di Wordpress stesso dovrebbe essere considerato una vulnerabilità.
Le auto Tesla si stanno schiantando perché Tesla è una specie di mina vagante.Per vedere un esempio migliore, guarda le auto a guida autonoma di Google.(Tesla ha letteralmente integrato capacità di guida autonoma senza dirlo a nessuno, quindi le ha abilitate silenziosamente con un ** aggiornamento software **.)
Non credo che gli incidenti stradali siano un buon confronto.Dal 1895 non vi è stato alcun modo per garantire che gli incidenti automobilistici non possano accadere e sono stati compiuti progressi nella riduzione del numero di incidenti (ad es. Linee bianche sulla strada, fari anabbaglianti, migliore progettazione degli incroci e dei semafori) e del loro impatto (airbag, cinture di sicurezza, zone sgualcite).Al contrario, l'iniezione SQL può essere completamente risolta con una modifica del design, punto.Le auto moderne non si schiantano perché le aziende sono scarsamente incentivate, incapaci, pigre o incompetenti, ma è per questo che esiste SQLi.
@EvanderConsus La società di sviluppo web.Sono stati incaricati di fornire un sito Web da utilizzare su Internet e ne hanno fornito uno non adatto allo scopo.Suggerire che potrebbero non essere responsabili perché i loro strumenti erano cattivi, dopo aver scelto strumenti gratuiti, ingiustificati e non supportati da persone sconosciute di abilità sconosciute, con molte vulnerabilità precedenti note, è semplicemente sciocco."* Ti abbiamo incaricato di costruire un nuovo edificio ed è caduto *", "* non è colpa nostra, abbiamo usato l'acciaio gratuito di alcuni fabbri amatoriali, come potremmo sapere che non sarebbe abbastanza forte?""Oh va bene"
Non capisco davvero cosa abbiano a che fare gli incidenti automobilistici con l'iniezione SQL.
@TessellatingHeckler Sono d'accordo che la responsabilità ricade sulla società di sviluppo.Tuttavia, vorrei sottolineare che gli strumenti ad alto costo, garantiti e supportati dal fornitore sono scritti anche da persone sconosciute con competenze sconosciute.Le persone, anche le persone altamente pagate in aziende altamente pagate, commettono errori e sarei cauto nel rilasciare una dichiarazione generale (che sembra quasi che tu stia facendo) che l'acciaio gratuito è sempre peggio [della roba costosa] (https://www.cvedetails.com/vulnerability-list.php?vendor_id=93&product_id=467&version_id=&page=1&order=3).
@WanderNauta Evander ha chiesto: ** Ora la domanda che viene sollevata, chi è il responsabile? "* - Non sto affermando che l'acciaio libero è sempre peggio, sto solo dicendo che non puoi compensare la tua responsabilità invocando" open source! ".raccogli l'acciaio gratuito da terra, non sottoporlo a test metallurgici e in seguito scopri che è debole, * tu * sei responsabile. In questa risposta, un difetto in un plug-in di Wordpress? L'autore del plug-in non ha mai accettato alcun contratto cheera adatto a qualsiasi scopo.Uno strumento del venditore potrebbe non essere migliore, ma se lo vendono come adatto allo scopo, non sei responsabile, lo sono.
La domanda sulla responsabilità è davvero retorica, non stavo facendo alcuna dichiarazione sull'open source, né sugli sviluppatori altamente pagati (quindi lo aggiungerò nella mia risposta)[email protected] Gli incidenti automobilistici non hanno davvero nulla a che fare con le SQL injection, ma è metaforicamente un modo di dire in cui una frase si applica a qualcosa a cui non è letteralmente applicabile per suggerire una somiglianza.
@TessellatingHeckler Sono curioso di sapere quale "modifica del design" risolverebbe l'iniezione SQL senza rompere il lato destro dell'operatore "IN".
@DamianYerrick progetta la tua applicazione in modo tale da poter parlare con il database solo dopo essere sfuggito a dati non controllati, utilizzando qualsiasi strumento di escape appropriato per la tua libreria / DB potrebbe essere uno.Sul lato database, [PostgreSQL] (https://dba.stackexchange.com/a/55018) e [H2database] (https://stackoverflow.com/a/3724272/478656) sembrano avere modi per passare array comeparametri singoli per evitare la costruzione di stringhe per questo scopo specifico.E [variazioni] (https://stackoverflow.com/a/189399/478656) sulla creazione di stringhe della query preparata: progettazione di app laboriosa, più lenta, ma comunque più sicura.
#10
+7
Colin Cassidy
2016-06-27 17:05:17 UTC
view on stackexchange narkive permalink

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.

sotto la crescente pressione di svolgere più lavoro in meno tempo, sono impegnati a risolvere un problema e passare a quello successivo, c'è poco tempo per riflettere quando si presenta il problema successivo.

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à.

"In secondo luogo, gli sviluppatori di Professione non sono stupidi ... è probabile che abbiano tutti titoli universitari" Lo sviluppatore più intelligente che abbia mai assunto aveva una laurea di due anni in una scuola di tecnologia.Alcuni dei peggiori avevano dottorati.Un pezzo di carta non infonde né intelligenza né buon senso, e ho visto una pervasiva mancanza di entrambi.Sfortunatamente il mondo accademico tende a valutare la carta rispetto all'esperienza, quindi ai nuovi sviluppatori vengono insegnate le cose sbagliate perché le persone che insegnano non conoscono meglio se stesse.
dimostra ancora che non sono stupidi.Mostra l'enorme disparità tra il mondo accademico e l'industria nel modo in cui viene insegnato agli sviluppatori di software.agli studenti viene insegnata la lingua de-jour, che probabilmente sarà javascript ... E questo è del tutto impraticabile di fronte a problemi o affidabilità del mondo reale, scalabilità delle prestazioni, dati non puliti, ecc. Ecc., Tutte cose che si finirebbe per dover gestire nelle applicazioni.
Le università sembrano insegnarti solo come sembrare intelligente senza sapere nulla di utile pratico.
no.Nel contesto della domanda originale, c'è pochissima attenzione sulla sicurezza del prodotto in un programma universitario
@colincassidy il tuo commento dovrebbe leggere, non c'è alcun focus sulla sicurezza del prodotto in un programma universitario.
#11
+7
Jedi
2016-06-29 21:58:06 UTC
view on stackexchange narkive permalink

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.

#12
+6
niilzon
2016-06-29 16:18:33 UTC
view on stackexchange narkive permalink

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à.

A volte, alcuni sviluppatori sottovalutano il rischio di SQLi.
Gli ignoranti di solito lo fanno.Mi ricorda un post su questo stesso sito, in cui uno studente aveva problemi con le domande.Gli ho mostrato come far funzionare il codice e gli ho fatto notare che era incline a SQLi, suggerendo di eseguire il refactoring del codice con PreparedStatements. La sua risposta è stata "ma è solo per un esercizio di classe, questo codice non verrà riutilizzato, non mi interessa". Questo è il tipo di atteggiamento contro cui dobbiamo combattere.Programmare nel modo più corretto possibile in tutte le occasioni è importante, * soprattutto se non padroneggi molto quello che stai facendo *.
#13
+4
Neil Davis
2016-06-29 06:54:18 UTC
view on stackexchange narkive permalink

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 ...

#14
+4
mystupidstory
2016-07-04 04:49:27 UTC
view on stackexchange narkive permalink

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.

#15
+2
Brad Thomas
2016-06-29 23:06:56 UTC
view on stackexchange narkive permalink

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.

#16
+1
pppp
2016-06-28 11:30:50 UTC
view on stackexchange narkive permalink

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.

Non sono sicuro che questo risponda alla domanda.Questo è stato inteso come un commento su un'altra risposta?
Credo che volesse dire che il motivo per cui SQL Injection esiste ancora è perché i suddetti "metodi sicuri" non proteggono completamente dalle SQL Injections e che le persone devono essere consapevoli di proteggersi completamente e assicurarsi di utilizzare un DBè in grado di gestire le situazioni necessarie.
Rendere il codice sicuro più difficile da scrivere si traduce in più bug e quindi in codice meno sicuro.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...