Perché la protezione contro l'iniezione SQL non è una priorità?

Su Stack Overflow, vedo molto codice PHP in domande e risposte che hanno query MySQL che sono altamente vulnerabili agli attacchi di iniezione SQL, nonostante le soluzioni alternative di base siano ampiamente disponibili per più di un decennio.

C'è un motivo per cui questi tipi di frammenti di codice sono ancora in uso oggi?

Penso che sia principalmente dovuto a) ignoranza b) pigrizia. I principianti di solito non sanno molto dell'iniezione di sql, e anche quando ne sentono parlare, lo ignorano perché è molto più semplice e facile da programmare in quel modo.

PHP rende deliberatamente molto, molto facile per le persone che sanno molto poco creare utili pagine Web dinamiche. Ciò significa che PHP attirerà molti principianti, che creano qualcosa di utile, imparano da altri esempi dall'aspetto utile e si voltano per insegnare agli altri come fare questa cosa interessante e utile. Il risultato è un sacco di codice errato e una scorta di programmatori che non conoscono meglio.

Non fa che peggiorare il fatto che gran parte dei programmatori competenti non voglia avere nulla a che fare con PHP. Ciò riduce la base di persone esperte che desiderano insegnare meglio agli altri. Ma perché evitano PHP? Bene per una combinazione di fattori. In parte non gli piace affrontare le verruche linguistiche. E in parte è perché preferirebbero lavorare con un buon codice e non c'è molto buon PHP là fuori.

Questa esatta costellazione di problemi utilizzati per infliggere Perl. A titolo di esempio lampante, prendiamo in considerazione il caso di Matt Wright, un adolescente entusiasta che ha iniziato a fornire molti script CGI utili, ben documentati e facili da installare negli anni '90. Sfortunatamente non capiva nulla della sicurezza, e nemmeno le persone che volevano usare le sue cose. Il risultato è stato il Matt Wright Script Archives, un flusso infinito di problemi di sicurezza per i primi script CGI. Nonostante sforzi come http://www.scriptarchive.com/nms.html , il problema non è migliorato per Perl fino a quando i provider di hosting condiviso hanno reso PHP più conveniente di ogni altra cosa. Ciò ha portato al problema nel passaggio da Perl a PHP.

Sfortunatamente ci sono tonnellate di tutorial PHP più che cattivi là fuori e alcuni vecchi libri PHP hanno anche fatto schifo nel dire alle persone di scrivere il codice corretto (non usando register_globals ecc.).

Inoltre, magic_quotes_gpcessendo stato abilitato in passato, alla gente non importava di scappare perché "semplicemente funzionava".

Personalmente, credo che PHP sia facile da usare, quindi naturalmente è facile da usare in modo improprio.

Come essere umano e programmatore, trovo straordinariamente facile commettere errori e trascurare certe cose, specialmente quando viene premuto per il tempo.

È facile, e forse anche troppo allettante, incolpare una certa lingua, per essere troppo accessibile per il suo bene. Ma questo sarebbe sorvolando il più grande problema della fallibilità umana, indipendentemente dalla lingua scelta per programmare.

Certo, abbiamo fatto molta strada dal linguaggio assembly, e penso che sarei una programmazione molto più produttiva in un linguaggio più moderno, come PHP, Python, Ruby o Java.

PHP (e altri linguaggi di scripting) hanno infatti abbassato la barriera all'ingresso. Ciò può significare che un numero maggiore di principianti nella programmazione prova prima PHP. Ma ciò non significa certamente che tutti i programmatori PHP siano in qualche modo meno qualificati o meno in grado di imparare dai propri errori rispetto ai programmatori di altre lingue.

Rasmus Lerdorf ha creato PHP nella sua forma originale nel 1994, da allora si è notevolmente evoluto. Nella sua incarnazione più moderna, supporta la programmazione orientata agli oggetti, nonché splendidi framework, come Symfony. PHP come linguaggio si è liberato dai suoi vincoli originali ed è cresciuto per offrire una grande flessibilità nel modo in cui i programmatori possono scegliere di usarlo. Puoi usarlo per creare uno script di 9.000 righe di codice spaghetti, oppure puoi utilizzarlo nel contesto di un moderno framework MVC, come Symfony: è la tua scelta!

Sospetto fortemente che le vulnerabilità della sicurezza non siano limitate a una sola lingua. È allettante scrivere tutti i programmatori PHP come in qualche modo meno capaci o più inclini a scrivere codice insicuro. Ma mi chiedo quanto di ciò sia il pregiudizio della lingua e quanto di fatto sia vero?

Penso che parte del problema siano le persone che semplicemente copiano il codice senza preoccuparsi di imparare quello che stanno facendo, ma davvero secondo me il modo in cui insegniamo il porgamnming è rotto ed è uno dei motivi per cui c'è così tanto codice cattivo. Insegniamo la sintassi fuori dal contesto e quindi i principianti non sanno quando usare qualcosa e quando non farlo o quali problemi la sintassi intende risolvere e quali problemi non intende risolvere. Quindi usano un martello quando una chiave sarebbe stata lo strumento migliore.

Ad esempio, invece di insegnare solo la sintassi, organizzi il corso come (Chiaramente ci sarebbero più passaggi, questo è solo un esempio di base di costruire da problemi di base a problemi più complessi piuttosto che insegnare solo la sintassi):

1. Ecco come impostare una pagina Web di base
2. Questo è il modo in cui la pagina Web estrae i dati da un database
3. Ecco come inviare i dati da una pagina Web a un database
4. Ecco come ti assicuri che vengano inviati i dati giusti.
5. Ecco come proteggere il database dall'immissione di dati dannosi

Penso che troverai una quantità simile di esempi MS SQL + ASP / ASP.NET altrettanto vulnerabili.

Sento che il problema deriva in parte dal fatto che quando stai provando a insegnare qualcosa, ad esempio filtrando i dati utilizzando una clausola WHERE, allora non vuoi davvero ingombrare il tuo esempio sfuggendo correttamente alla stringa di query o utilizzando un comando parametrizzato.

Ho addestrato gli sviluppatori per molti anni e posso entrare in empatia con le persone che scrivono codice orribile in tutorial. A volte è il più facilmente comprensibile. Tuttavia, a parte sottolineo sempre il codice vulnerabile e lo trasformo in un argomento secondario interessante.

L'autore originale di PHP, Rasmus Lerdorf , nel suo famigerato post sul blog sostiene lo sviluppo "no-framework" . Sebbene per le query SQL utilizzi PDO, non vi è alcun rischio di iniezione SQL. Ancora piuttosto brutto e obsoleto rispetto ai moderni framework MVC con i livelli ORM.

Puoi incolpare questa povera pratica sul PHP stesso. Le versioni legacy di PHP (fino al 2006 circa) sfuggirebbero a tutte le variabili di input GET e POST in modo che fossero adatte all'interpolazione delle query del database BY DEFAULT. Vedi http://php.net/manual/en/security.magicquotes.php

Non confondere lo scopo di un tutorial, che è quello di dimostrare qualcosa semplicemente, con ciò che dovrebbe essere fatto in un ambiente di produzione. Ad esempio, la maggior parte del codice tutorial che ho scritto ha poca o nessuna verifica di errori / eccezioni. Cerco di ricordare al lettore che il codice dimostra solo come eseguire un'attività specifica, non come coprire tutti i possibili risultati.

Quando stavo imparando PHP ho guardato alcuni di questi libri PHP + MySQL e sì, sento che contribuisce a quella cattiva pratica. Ma ho simpatia, perché insegnano la lingua , non buone pratiche di programmazione. Altrimenti dove finirebbe?