Domanda:
Perché le persone dicono che PHP è intrinsecamente insicuro?
Moshe
2010-11-21 21:54:46 UTC
view on stackexchange narkive permalink

Ho sentito dire che PHP è intrinsecamente insicuro. È vero? Perché?

Nove risposte:
#1
+27
nealmcb
2010-12-25 00:33:54 UTC
view on stackexchange narkive permalink

È 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

Uno dei cinque link sopra indica un forum che è stato spostato altrove, e c'è la garanzia che l'archivio del sito a cui ti sei collegato rimarrà molto più a lungo. Potresti riassumere i risultati di quei collegamenti nella tua risposta per farla vivere più a lungo?
#2
+11
Smit Johnth
2013-11-26 13:48:51 UTC
view on stackexchange narkive permalink

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.

  • Guarda questo. Pensi di confrontare 2 variabili come stringhe? Ops, non lo sei! Ancora più divertente, il mio preferito. Non tutti coloro che sono in grado di scrivere un motore di forum in PHP possono confrontare correttamente 2 stringhe.
Ciao. La tua risposta ha il contenuto più * effettivo * finora nel thread ma termina con riferimenti a due link molto poco esplicativi. C'è qualche possibilità che riassumi il contenuto di queste due pagine nella tua risposta? Ciò gli consentirà di sopravvivere al sito a cui stai puntando.
@SteveDL "Se confronti un numero con una stringa o il confronto coinvolge stringhe numeriche, ogni stringa viene convertita in un numero e il confronto viene eseguito numericamente." - quindi se pensi di confrontare due stringhe con == come stringhe - non lo sei.
#3
+7
Andreas Arnold
2010-11-22 19:31:14 UTC
view on stackexchange narkive permalink

Ci sono almeno due punti per questo:

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

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

  3. ol>
#4
+4
anonymous
2010-11-21 22:08:51 UTC
view on stackexchange narkive permalink

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.

Questo non è vero. PHP ha molti hack, ma non ha nulla a che fare con l'insicurezza. Qualsiasi programma complesso ha bug, alcuni dei quali sarebbero legati alla sicurezza, quindi indicare l'elenco dei bug come prova di "insicurezza intrinseca" è inutile e fuorviante.
@StasM, stai cercando di dire che non ci sono vulnerabilità nell'interprete PHP o hai interpretato male una parte della mia terza frase? Certo, solo gli hack non sono la ragione dell'insicurezza. Nella mia terza parte della frase "[...], quello [...]" è più correlato all'inizio.
@Ams ovviamente ci sono (c'erano) vulnerabilità, come in qualsiasi altro software abbastanza grande e popolare. Questo tuttavia non significa in alcun modo una certa "insicurezza intrinseca".
#5
+2
StasM
2010-12-24 14:34:11 UTC
view on stackexchange narkive permalink

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

Questo è un motivo valido, ma non è l'unico.
#6
+2
user42178
2015-05-10 00:13:05 UTC
view on stackexchange narkive permalink

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.

#7
+1
ThiefMaster
2010-11-21 22:33:27 UTC
view on stackexchange narkive permalink

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.

Credo che la domanda di @Moshe's riguardasse le insicurezze dell'interprete PHP. E per favore, senza parole scortesi.
Come osano creare un linguaggio di programmazione facile. Com'è odioso da parte delle persone normali imparare queste semplici lingue. Penso che dovremmo trovare più modi per trovare difetti in essi. Quelli che entrano nel regno della programmazione senza la tua approvazione, quelli che commettono atti blasfemi contro la sacra arte della programmazione. Dovrebbero essere uccisi.
@DMin Così molto vero! :) Tuttavia, c'è ancora un argomento da sostenere. Ad esempio, non si può praticare la medicina senza una formazione adeguata, a causa dei possibili danni causati. La stessa analogia potrebbe essere tracciata per i servizi Internet pubblici, poiché un difetto di sicurezza causa danni. Nota che non sto dicendo che penserei che * dovrebbe * essere trattato allo stesso modo (in effetti, penso proprio il contrario), solo che l'analogia ha qualche merito.
#8
  0
djozsef
2015-05-10 15:08:12 UTC
view on stackexchange narkive permalink

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.

#9
-1
John M
2018-03-15 02:23:01 UTC
view on stackexchange narkive permalink

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.

"Non è compilato o crittografato" - Essere interpretato non lo rende intrinsecamente meno sicuro, e perché dovrebbe essere crittografato?
"se hai il codice sorgente hai anche i dettagli di accesso per il database" - Non necessariamente vero, sebbene sia comune (se stai contando i file di configurazione).Non proprio specifico per php però.
È meno sicuro perché il codice giace su una macchina connessa al Web, probabilmente compromessa in testo normale.Non archivieresti le informazioni sensibili del database in testo normale, quindi perché dovresti mantenere il codice sensibile in testo normale?
@JohmM Cosa ti fa pensare che il codice compilato sia più sicuro?Se segui la massima di Shannon, non dovresti comunque basare la tua sicurezza sulla segretezza del tuo codice.
Aggiunge un altro piccolo livello di sicurezza oltre a ciò che è già presente.Chiunque prenda i file deve eseguire il processo aggiuntivo di provare a decodificarli.La massima di Shannon non ti farà molto bene se un server con cui sei costretto a lavorare è già stato compromesso.Non sai se il tuo server è stato violato o meno, perché non tutti gli hacker gridano di aver compromesso la tua macchina.Ovviamente metti in atto anche altre pratiche di sicurezza per cercare di impedire che l'attacco iniziale si verifichi in primo luogo.Devi fare molte cose per proteggere un sistema.
Il problema con Wordpress non è che sia insicuro, ma molti plugin popolari non sono sicuri.Lo stesso vale per molti programmi estensibili come Apache, il cui core è abbastanza sicuro ma le cui estensioni gli danno un brutto nome.Si noti inoltre che a volte i programmi interpretati sono in realtà _più_ sicuri, poiché in genere sono sicuri per la memoria.
Ho segnalato un caso in cui wordpress può essere facilmente compromesso a causa della procedura di installazione.Ovviamente ci sono modi per prevenire questa vulnerabilità, ma la maggior parte dei tutorial là fuori non usa questi metodi.Hai ragione, anche i plugin presentano un rischio per la sicurezza.Per impostazione predefinita, i plugin hanno accesso al file system e al database.Questo non è davvero un esempio di php insicuro, è più la comunità PHP che promuove pratiche pericolose.Uno dei problemi con PHP è che offre agli sviluppatori di basso livello la possibilità di consentire l'accesso a cose che non sanno come proteggere.


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