Ho sentito dire che PHP è intrinsecamente insicuro. È vero? Perché?
È piuttosto difficile per una lingua essere "intrinsecamente insicura" secondo la mia definizione, dal momento che un buon programmatore può adattarsi. Ma PHP ha iniziato a lasciare 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 integrare nel software di base e nelle librerie. L'addestramento alla sicurezza è difficile nelle migliori circostanze, e ancora di più quando un grosso sottogruppo di sviluppatori non ha esperienza e ha iniziato con impostazioni errate.
Ad esempio, non era fino alla versione 4.2.0 che register_globals era disabilitato di default, quindi i dati ricevuti attraverso la rete non venivano più inseriti direttamente nello spazio dei nomi globale. Questa funzionalità è finalmente prevista per la rimozione completa nella prossima versione.
Il rilascio anticipato di PHP e la facilità di distribuzione di semplici applicazioni PHP hanno attirato molti sviluppatori con scarsa consapevolezza della sicurezza e assicurato un numero elevato di applicazioni, un numero significativo delle quali aveva vulnerabilità sfruttabili a distanza. Anche la dimensione e la vulnerabilità della base operativa hanno suscitato molto interesse da parte della comunità degli exploit.
Ecco alcuni riferimenti e link utili
Alcuni di questi motivi sono descritti in "Frattale di cattiva progettazione ".
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 i documenti Python per cose insicure come la serializzazione ( pickle ), vedrai un avviso rosso su la parte superiore della pagina "Non utilizzare su input non attendibili!". 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 the wild.
PHP viene eseguito solo come CGI, ovvero reinizializzazione completa di uno script a ogni richiesta. E questo provoca odio per le strutture: "Sono lenti!". Ma i framework eliminano le vulnerabilità di injection code (iniezioni SQL - al 100%). C'è una differenza principale: le dichiarazioni preparate sono sicure per impostazione predefinita. Non devi fare nulla per proteggerti dalle iniezioni SQL, il che significa che non puoi dimenticarlo o non saperlo. Il loro mancato utilizzo non è sicuro per impostazione predefinita: hai un difetto di sicurezza a meno che non lo aggiusti manualmente ogni volta.
Lo stesso interprete PHP è rotto. Quel velenoso zero bug in cui l'API interpreta \ 0 come terminatore di stringa mentre php stesso non lo fa - perché non lo ha python ??
Weak typing (i.e., silent automatic conversion between strings/numbers/et al) is so complex that whatever minor programmer effort is saved is by no means worth it.
Ci sono almeno due punti a questo:
PHP è molto onnipresente e questo lo rende un obiettivo interessante per gli hacker. Significa anche che molti programmatori alle prime armi usano PHP, perché è facile da usare. Quindi è più probabile che raccolga codice non sicuro se includi librerie di terze parti nella tua applicazione.
E immagino che il punto più importante è che PHP non è stato progettato per essere utilizzato sulla scala 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 lo ha scritto, e molte delle cose che ha deciso di usare di nuovo (perché era più facile da programmare) ora sono rischi per la sicurezza.
L'argomento più popolare è - maggiore attenzione che ne deriva. Questa è la prima verità. La seconda verità è che PHP dall'inizio non era molto ben progettato e al giorno d'oggi ha un sacco di hack interni per funzionare bene, che porta coerentemente a fallimenti nelle implementazioni di sicurezza, incompatibilità di versioni. Come prova migliore puoi controllare MOPS . Davvero non penso che ci sia altro da discutere.
No, non è vero. Puoi scrivere codice sicuro in PHP perfettamente bene. Tuttavia, un sacco di codice scritto in PHP è non sicuro, e la ragione è semplice: PHP ha una barriera di ingresso relativamente bassa, il che significa che molte persone che sanno poco scrivere in PHP in sicurezza. D'altra parte, PHP è orientato al web, il che significa che l'applicazione pubblica PHP può essere attaccata da chiunque su Internet (mentre, ad esempio, l'applicazione C ++ per il desktop di solito può essere attaccata solo da qualcuno che ha già accesso a detto computer desktop).
I problemi principali sono la configurazione predefinita e la barriera bassa di immissione.
Il modo più semplice per implementare un'app PHP è installare l'horror inefficiente chiamato "Apache" con mod_php , lanciare l'app mal sviluppata in /var/www e guardare il mondo a bruciare. Funzionerà, ma è un disastro per la sicurezza.
Ad esempio, un'app Node.js viene eseguita come un proprio processo, nella propria directory totalmente indipendente dalla radice Web. La web root è lì solo per archiviare risorse e contenuti caricati dagli utenti, 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 brutto (potrebbe causare danni sul lato client come phishing o XSS ma è fuori portata).
D'altra parte, usando la nostra configurazione PHP predefinita, se un file .php viene caricato e richiesto, viene eseguito sotto i privilegi dell'app legittima, può accedere e modificare i suoi file, accedere e sfogliare i dati sensibili dal DB , ecc. Questo è un disastro e la maggior parte dei compromessi dei siti PHP provengono da moduli di caricamento di file non sicuri.
Ci sono modi per renderlo sicuro, come separare l'app e il contenuto - i file dell'app non dovrebbero essere accessibili tramite la web root e nessun file dovrebbe essere eseguito dalla directory dei contenuti. La maggior parte dei framework utilizza questo approccio, in cui tutti i controller, i modelli e le visualizzazioni risiedono nella directory app e una seconda cartella public contiene tutte le risorse, il contenuto caricato e un singolo file index.php che rappresenta il punto di accesso dell'app ed è usato per avviare il framework e l'app. Quindi si configura il server Web per utilizzare la directory public come web root e solo eseguire index.php mentre serve tutto il resto come contenuto. Anche se viene caricato un file .php dannoso, verrà pubblicato come testo normale, in modo che tutto il mondo possa ferire gli occhi di fronte al tentativo di un idiota di compromettere un sito web.
Quindi perché non tutti lo fanno? A causa di " ciao come installo il framework laravel su cpanel hosting gratuito? Thx "
A causa di persone come queste. La barriera di ingresso veramente bassa significa che un po 'di utenti PHP non sono sviluppatori e non vogliono diventare sviluppatori - si noti che non li considero sviluppatori perché copiare / incollare codice da tutorial senza capirlo non significa essere uno sviluppatore, che significa solo essere un idiota irresponsabile: diventi uno sviluppatore solo quando sei in grado di prendere tempo per capire cosa stai facendo e come puoi fare cose nel modo giusto . Potrei essere di parte, ma questo significa anche andare a Stack Exchange e leggere alcune cose di base sulla sicurezza del server prima di configurare un server web con connessione internet. ;)
Dato che non possono usare le linee guida di sicurezza applicate né utilizzare framework su hosting condiviso (e non preoccuparsi di spostarsi 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 di PHP è spesso gratuito) continuano a creare applicazioni scadenti e non sicure e distribuirli su server di hosting condiviso crappy e già compromessi e già compromessi.
Ci sono molti idioti che sono in grado di scrivere codice PHP perché è un linguaggio molto semplice.
Ciò si traduce in un sacco di codice non sicuro, in particolare i buchi di inclusione del codice in stile include($_GET['page']) (remoto), i fori XSS ei buchi di SQL injection.
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 un codice orribile e insicuro è inferiore.
Un altro aspetto: Zend baserebbe la propria azienda sullo stack PHP mirato che è più vulnerabile della concorrenza? Non è la lingua quella da incolpare per l'insicurezza. È il design. Il cattivo design può essere implementato in tutte le lingue. La sicurezza non è uno stato, è un processo. E la massiccia base contributiva di PHP fa un ottimo lavoro.
Il codice è memorizzato in file di testo in formato testo (.pdf). 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 eliminare, eliminare, inserire o selezionare. 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 è un favorito per le persone senza abilità del server o capacità di programmazione. Ciò significa che non sanno come proteggerlo correttamente. È così ampiamente usato che tutte le vulnerabilità scoperte vengono pubblicate e sfruttate. La maggior parte degli sviluppatori non ha idea di cosa stia realmente facendo il codice sul proprio sito WordPress. Ancora una volta WordPress memorizza i dettagli di accesso al database nel file wp-config.php in chiaro e ha un processo di installazione molto poco sicuro. Per impostazione predefinita, il programma di installazione è eseguibile senza password fintanto che wp-config.php è configurato e il database (senza tabelle) è impostato. Se non sei abbastanza veloce, qualcuno eseguirà il programma di installazione per te e installerà alcuni 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 è pericolosa. Così tanti tutorial là fuori incoraggiano l'uso di localhost nelle stringhe di connessione al database. Eseguire il tuo database sullo stesso computer del tuo codice Web, o una macchina direttamente rivolta al web in generale, è una cattiva pratica. La macchina per il Web non deve avere il database su di essa.