Moshe
2010-11-21 21:54:46 UTC
Ho sentito dire che PHP è intrinsecamente insicuro. È vero? Perché?
Ho sentito dire che PHP è intrinsecamente insicuro. È vero? Perché?
È piuttosto difficile per un linguaggio essere "intrinsecamente insicuro" secondo la mia definizione, dal momento che un buon programmatore può adattarsi. Ma PHP ha iniziato lasciando molti campi minati in giro per i principianti.
Le versioni iniziali di PHP prestavano poca attenzione alla sicurezza e il design aveva alcuni grossi difetti. La sicurezza è difficile da aggiornare nel software principale e nelle librerie. La formazione sulla sicurezza è difficile nelle migliori circostanze, e lo è ancora di più quando un ampio sottoinsieme di sviluppatori è inesperto e ha iniziato con cattive impostazioni predefinite.
Ad esempio, non è stato fino alla versione 4.2.0 che register_globals era disabilitato per impostazione predefinita, quindi i dati ricevuti sulla rete non venivano più inseriti direttamente nello spazio dei nomi globale. Questa funzione è finalmente prevista per la rimozione completa nella prossima versione.
Il rilascio anticipato di PHP e la facilità di distribuzione di semplici applicazioni PHP hanno anche attratto molti sviluppatori con poca consapevolezza della sicurezza e hanno assicurato un gran numero di applicazioni, un numero significativo dei quali aveva vulnerabilità sfruttabili da remoto. Anche le dimensioni e la vulnerabilità della base distribuita hanno suscitato molto interesse da parte della comunità degli exploit.
Di seguito sono riportati alcuni riferimenti e collegamenti utili
Alcuni di questi motivi sono descritti in "Frattale di un cattivo design".
PHP è il cieco che guida il cieco. Ho letto il wikibook PHP; dovrebbe essere chiamato "come scrivere un'applicazione assolutamente vulnerabile". Non riesco a immaginare che possa essere pubblicato in qualsiasi altra lingua.
Relazione con la sicurezza. Se leggi documenti Python per cose insicure come la serializzazione ( pickle), vedrai un avviso rosso nella parte superiore della pagina "Non utilizzare su input non attendibile!". Che ne dici di PHP?
Oltre all'elemento precedente: in altre lingue, il codice è considerato un problema se non si capisce cosa fa e come funziona. In PHP, il codice è considerato un problema se ci sono exploit in circolazione.
PHP viene eseguito solo come CGI, il che significa reinizializzazione completa di uno script ad ogni richiesta. E questo provoca odio ai quadri: "Sono lenti!". Ma i framework eliminano le vulnerabilità di iniezione di codice (SQL injection - al 100%). C'è una differenza principale: le istruzioni preparate sono sicure per impostazione predefinita. Non devi fare nulla per proteggerti dalle iniezioni SQL, ciò significa che non puoi dimenticarlo o non saperlo. Non usarli non è sicuro per impostazione predefinita: hai un difetto di sicurezza a meno che non lo aggiusti manualmente ogni volta.
L'interprete PHP stesso è guasto. Quel velenoso zero bug in cui l'API interpreta \ 0 come il terminatore di stringa mentre php stesso no - perché Python non ce l'ha ??
Digitazione debole (cioè, la conversione automatica silenziosa tra stringhe / numeri / et al) è così complessa che qualunque piccolo sforzo del programmatore venga risparmiato non ne vale assolutamente la pena.
Ci sono almeno due punti per questo:
PHP è molto diffuso e questo lo rende un bersaglio interessante per gli hacker. Significa anche che molti programmatori inesperti usano PHP, perché è facile da usare. Quindi è più probabile che tu riceva codice non sicuro se includi librerie di terze parti nella tua applicazione.
E immagino che il punto più importante sia che PHP non è stato progettato per essere usato sulla bilancia che è oggi. Rasmus Lerdorf ha scritto PHP per sostituire alcuni script Perl che ha usato, e da lì è cresciuto. Quindi la sicurezza non era l'aspetto più importante quando l'ha scritta, e molte delle cose che ha deciso di usare prima (perché era più facile da programmare) ora sono rischi per la sicurezza.
L'argomento più popolare è: maggiore attenzione deriva. Questa è la prima verità. La seconda verità è che PHP dall'inizio non era molto ben progettato e oggigiorno ha molti hack interni per funzionare bene, il che porta costantemente a errori nelle implementazioni di sicurezza, incompatibilità di versioni. Come prova migliore puoi controllare MOPS. Non credo proprio che ci sia altro da discutere.
No, non è vero. Puoi scrivere codice sicuro in PHP perfettamente. Tuttavia, molto codice scritto in PHP è insicuro e il motivo è semplice: PHP ha una barriera di accesso relativamente bassa, il che significa che molte persone che sanno poco di sicurezza scrivono in PHP. D'altra parte, PHP è orientato al web, il che significa che l'applicazione PHP pubblica può essere attaccata da chiunque su Internet (mentre, ad esempio, l'applicazione C ++ per desktop può solitamente essere attaccata solo da qualcuno che ha già accesso a detto computer desktop).
I problemi principali sono la configurazione predefinita e la bassa barriera di accesso.
Il modo più semplice per distribuire un'app PHP è installare l'orrore inefficace chiamato "Apache" con mod_php , lancia l'app mal sviluppata in / var / www e guarda il mondo bruciare. Funzionerà, ma è un disastro per la sicurezza.
Ad esempio, un'app Node.js viene eseguita come processo a sé stante, nella propria directory totalmente indipendente dalla radice web. La radice web è lì solo per archiviare risorse e contenuti caricati dall'utente e può essere omessa se l'app non ne ha bisogno (se è solo un'API REST, ad esempio). Se un file .js viene caricato lì, non accadrà nulla di male (potrebbe causare danni lato client come phishing o XSS, ma questo è fuori portata).
D'altra parte, utilizzando la nostra configurazione PHP predefinita, se un file .php viene caricato e richiesto, viene eseguito con i privilegi dell'app legittima, può accedere e modificare i suoi file, accedere ed esfiltrare dati sensibili dal DB, ecc. Questo è un disastro e la maggior parte dei siti PHP compromessi provengono da moduli di caricamento file non sicuri.
Esistono modi per renderlo sicuro, come separare l'app e il contenuto: i file dell'app non dovrebbero essere accessibili tramite la radice Web e nessun file dovrebbe essere la directory dei contenuti. La maggior parte dei framework utilizza questo approccio, in cui tutti i controller, i modelli e le viste risiedono nella directory app e una seconda directory public contiene tutte le risorse, i contenuti caricati e un singolo index.php che è il punto di ingresso dell'app e viene utilizzato per avviare il framework e l'app. Quindi configura il server web per usare la directory public come root web ed esegui solo index.php mentre servi tutto il resto come contenuto. Anche se viene caricato un file .php dannoso, verrà servito solo come testo normale, affinché il mondo intero si ferisca gli occhi di fronte al tentativo di un idiota di compromettere il sito web.
Allora perché non lo fanno tutti? A causa di " ciao come installo il framework laravel sull'hosting gratuito di cpanel? Thx "
a causa di persone come quelle. La barriera di accesso davvero bassa significa che un bel po 'di utenti PHP non sono sviluppatori e non vogliono diventare sviluppatori - nota che non li considero sviluppatori perché copiare / incollare codice da tutorial senza capire che non significa essere uno sviluppatore, questo significa solo essere un idiota irresponsabile: diventi uno sviluppatore solo quando puoi prenderti il tempo per capire cosa stai facendo e come puoi fare le cose nel modo giusto. Potrei essere di parte, ma questo significa anche andare su Stack Exchange e leggere alcune cose di base sulla sicurezza del server prima di configurare un server web con connessione a Internet. ;)
Dato che non possono utilizzare applicare le linee guida di sicurezza né utilizzare framework su hosting condiviso (e non preoccuparti di spostarti su VM / server dedicati perché richiede una lettura che non vogliono fare perché l'hosting condiviso sembra abbastanza buono per loro, e l'hosting condiviso PHP è spesso gratuito) continuano a creare applicazioni scadenti e insicure e le distribuiscono su server di hosting condiviso cPanel già compromessi.
Ci sono molti idioti che sono in grado di scrivere codice PHP in quanto è un linguaggio molto semplice. Ciò si traduce in un sacco di codice non sicuro, in particolare include ($ _ GET ['page']) - Fori di inclusione di codice di stile (remoto), fori XSS e fori di iniezione SQL.
Python e Java non sono così popolari per le persone che non hanno mai programmato prima, quindi ci sono meno neofiti di programmazione e quindi la possibilità di codice orribile insicuro è inferiore.
Un altro aspetto: Zend baserebbe la propria azienda su uno stack PHP mirato che è più vulnerabile della concorrenza? Non è il linguaggio da incolpare dell'insicurezza. È il design. Un cattivo design può essere implementato in ogni lingua. La sicurezza non è uno stato, è un processo. E l'enorme base di contributori di PHP fa un ottimo lavoro.
Il codice è memorizzato in file di testo formattato in chiaro (. Php). Non è compilato o crittografato, quindi chiunque comprometta la tua macchina ottiene il tuo codice sorgente. E se hanno il codice sorgente, hanno anche i dettagli di accesso per il database e possono eseguire query come rilascia, elimina, inserisci o seleziona. Anche asp viene compilato prima di essere distribuito. La maggior parte delle persone che usano php sono sviluppatori intermedi che sanno molto poco sulla sicurezza del server.
Poi c'è WordPress. La maggior parte dei siti php esegue WordPress. WordPress è uno dei preferiti per le persone senza competenze sul server o capacità di programmazione. Ciò significa che non sanno come proteggerlo correttamente. È così ampiamente utilizzato che tutte le vulnerabilità scoperte vengono pubblicate e sfruttate. La maggior parte degli sviluppatori non ha idea di cosa stia effettivamente facendo il codice sul proprio sito WordPress. Ancora una volta WordPress memorizza i dettagli di accesso al database nel file in chiaro wp-config.php e ha un processo di installazione molto poco sicuro. Per impostazione predefinita, il programma di installazione è eseguibile senza password finché è configurato wp-config.php e il database (senza tabelle) è impostato. Se non sei abbastanza veloce, qualcuno eseguirà il programma di installazione per te e installerà alcuni simpatici strumenti di gestione dei file per leggere più file sul tuo sistema. Poi c'è l'enumerazione degli utenti e vari altri problemi.
Molte persone usano ancora php 5.x per i loro progetti. Alcune di queste versioni non ricevono più aggiornamenti di sicurezza.
Anche la stessa comunità php è un pericolo per se stessa. Così tanti tutorial là fuori incoraggiano l'uso di localhost nelle stringhe di connessione al database. L'esecuzione del database sulla stessa macchina del codice rivolto al Web o in generale su una macchina rivolta direttamente al Web è una cattiva pratica. La macchina che si affaccia sul Web non dovrebbe contenere il database.