Su Stack Overflow, vedo un sacco di codice PHP in domande e risposte che hanno query MySQL che sono altamente vulnerabili agli attacchi SQL injection, nonostante soluzioni alternative di base siano ampiamente disponibili da più di un decennio.
C'è una ragione 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 di SQL injection, e anche quando ne sentono parlare lo ignorano perché è molto più semplice e facile da codificare in questo modo.
PHP lo rende volutamente veramente facile per le persone che sanno ben poco per creare utili pagine web dinamiche. Ciò significa che PHP attirerà molti principianti, che creeranno qualcosa di utile, impareranno da altri esempi utili e si gireranno per insegnare agli altri come fare questa cosa interessante e utile. Il risultato è un sacco di codice cattivo e un'offerta di programmatori che non conoscono meglio.
Fa solo peggiorare le cose che una grande parte di programmatori competenti non vogliono avere nulla a che fare con PHP. Questo riduce la base di persone esperte che sono disposte ad insegnare meglio agli altri. Ma perché evitano PHP? Bene per una combinazione di fattori. In parte a loro non piace avere a che fare con le verruche linguistiche. E in parte è perché preferirebbero lavorare con un buon codice, e non ci sono molti buoni PHP là fuori.
Questa esatta costellazione di problemi usati per infliggere Perl. Come esempio brillante, consideriamo il caso di Matt Wright, un adolescente entusiasta che si proponeva di fornire molti script CGI utili, ben documentati e facili da installare negli anni '90. Sfortunatamente non ha capito nulla della sicurezza, e nemmeno le persone che volevano usare le sue cose. Il risultato è stato Matt Wright Script Archives, che è stato un flusso infinito di problemi di sicurezza per i primi script CGI. Nonostante sforzi come link , il problema non è migliorato per Perl fino a quando i provider di hosting condiviso non hanno reso PHP più conveniente di qualsiasi altra cosa. Ciò ha portato al passaggio del problema da Perl a PHP.
Sfortunatamente ci sono tonnellate di tutorial PHP più che errati là fuori e alcuni libri di PHP più vecchi sono anche risucchiati a dire alle persone di scrivere codice corretto (non usando register_globals ecc.).
Inoltre, con magic_quotes_gpc attivato in passato, le persone non si sono preoccupate di eseguire l'escape perché "funzionava semplicemente".
Personalmente, credo che PHP sia facile da usare, quindi naturalmente è facile abusarne.
Come umano e programmatore, trovo estremamente facile fare errori e trascurare certe cose, soprattutto se premuto per un po 'di tempo.
È facile, e forse anche troppo allettante, dare la colpa a un certo linguaggio, essere troppo accessibili per il suo bene. Ma questo dovrebbe sorvolare il problema più grande della fallibilità umana, indipendentemente dalla lingua scelta per programmare.
Certo, abbiamo fatto molta strada dal linguaggio assembly e penso che sarei molto più produttivo in un linguaggio più moderno, come PHP, Python, Ruby o Java.
PHP (e altri linguaggi di scripting) hanno di fatto abbassato la barriera all'ingresso. Ciò potrebbe significare che più nuovi arrivati alla programmazione provano prima PHP. Ma questo non significa certamente che tutti i programmatori PHP sono 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 è evoluto considerevolmente. Nella sua più moderna incarnazione, supporta la programmazione orientata agli oggetti, oltre a framework superbi, 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 9000 righe di codice spaghetti, oppure puoi usarlo nel contesto di un moderno framework MVC, come Symfony: è la tua scelta!
Sospetto strongmente che le vulnerabilità della sicurezza non siano limitate a una singola lingua. Si è tentati di cancellare tutti i programmatori PHP come in qualche modo meno capaci, o più inclini a scrivere codice non sicuro. Ma mi chiedo quanto di questo sia il pregiudizio della lingua, e quanto è fatto?
Penso che parte del problema siano le persone che semplicemente copiano il codice senza preoccuparsi di imparare quello che stanno facendo, ma a mio parere il modo in cui insegniamo il porgamming è 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 no o quali problemi la sintassi intende risolvere e quali problemi non è destinato a risolvere. Quindi usano un martello quando una chiave inglese sarebbe stata lo strumento migliore.
Quindi, per esempio, invece di insegnare solo la sintassi, organizzi il corso come (ovviamente ci sarebbero più passaggi, questo è solo un esempio di base per costruire dai problemi di base a quelli più complessi piuttosto che insegnare la sintassi):
Penso che troverai una quantità simile di esempi MS SQL + ASP / ASP.NET altrettanto vulnerabili.
Ritengo che il problema derivi in parte dal fatto che quando provi a insegnare qualcosa, ad esempio filtrando i dati utilizzando una clausola WHERE, non vuoi davvero ingombrare il tuo esempio evadendo correttamente la stringa della query o utilizzando un parametro parametrizzato comando.
Ho formato gli sviluppatori per molti anni e posso entrare in empatia con persone che scrivono codice orribile nei tutorial. A volte è più facile da capire. Tuttavia, a parte sottolineo sempre il codice vulnerabile e lo trasformo in un argomento collaterale interessante.
Autore originale di PHP, Rasmus Lerdorf , nel suo famigerato blog avvoca lo sviluppo" no-framework " . Anche se per le query SQL utilizza PDO, non vi è alcun rischio di SQL injection. Ancora piuttosto brutto e obsoleto rispetto ai moderni quadri MVC con livelli di ORM.
Non confondere lo scopo di un tutorial, che è quello di dimostrare qualcosa semplicemente, con quello che dovrebbe essere fatto in un ambiente di produzione. Ad esempio, la maggior parte del codice tutorial che ho scritto ha pochi errori o nessun controllo di eccezione. Cerco di ricordare al lettore che il codice dimostra solo come eseguire un compito specifico, non come coprire tutti i possibili risultati.
Quando stavo imparando il PHP ho guardato alcuni di questi libri PHP + MySQL, e sì, sento che contribuisce a quella cattiva pratica. Ma ho simpatia, perché stanno insegnando il linguaggio , non buone pratiche di programmazione. Altrimenti dove finirà?