I dati sensibili in uno script PHP sono protetti?

3

Ho sentito che PHP è alquanto sicuro perché Apache non consente il download di PHP non elaborato. Questo è affidabile, però? Ad esempio, se si desidera proteggere con password qualcosa, ma non si vuole creare un database, qualcosa di simile a $pass = "123454321"; può essere sicuro?

In conclusione, è lecito ritenere che nessuno abbia accesso al vero file .php?

    
posta tkbx 30.11.2012 - 22:21
fonte

2 risposte

9

Hai ragione che Apache invierà script PHP all'interprete PHP, se configurato correttamente , ma quello che stai descrivendo è non sicuro.

Né la lingua né il server web sono rilevanti qui, i valori di configurazione non dovrebbero essere in una directory accessibile pubblicamente per cominciare, non c'è assolutamente alcuna ragione per avere il tuo file di configurazione sotto DocumentRoot .

Infine, se qualcuno non ha accesso al server, non puoi mai presumere che nessuno abbia accesso ai tuoi file.

    
risposta data 30.11.2012 - 22:33
fonte
7

Se non commetti errori, le origini PHP non possono essere lette dall'esterno: finché apache è configurato per gestire file .php tramite mod_php, verranno sempre eseguiti, mai pubblicati come non elaborati.

Tuttavia, gli errori sono facili da fare e si trovano spesso nel codice di produzione. Gli errori tipici includono:

  • Vulnerabilità di attraversamento del percorso. Lo schema tipico è che tu costruisci un nome di file basato su qualche input dell'utente (ad esempio un parametro $_GET ), quindi servi questo file attraverso, diciamo, readfile . Ad esempio, se hai readfile("/home/me/pages/{$_GET['pageid']}.html") , un utente malintenzionato può facilmente piantare qualcosa come "../../../../../../../../../../../etc/shadow" .
  • File PHP con estensioni non standard. Apache utilizza l'estensione per determinare il tipo MIME di un file e decide in seguito come gestirlo. config.php sarà interpretato, ma config.php.inc no; dal momento che .inc non è un'estensione nota nella maggior parte delle configurazioni, Apache usa il testo in chiaro, il che significa che il codice sorgente può essere richiesto sulla rete.
  • Caricamento del codice. In genere, tale vulnerabilità si verifica quando si dispone di caricamenti di file gestiti in modo improprio, ad es. autorizzare le directory arbitrarie nel nome file caricato o il caricamento in un percorso sotto la radice del documento. Quando un utente malintenzionato riesce a piantare .php file in una posizione in cui vengono eseguiti, è possibile eseguire codice PHP arbitrario sul server, incluso il codice che legge altri script ed estrae le password.
  • Vulnerabilità nell'esecuzione di codice in modalità remota. Simile al caricamento del codice; se hai eval , include , system , exec o chiamate simili nel tuo codice, e i loro argomenti sono parzialmente forniti dall'utente, potresti essere nei guai: gli input non correttamente sterilizzati a uno di questi costrutti possono consentire agli aggressori di eseguire codice PHP o comandi shell arbitrari.
  • Visualizzazione degli errori nell'output della pagina. Molti errori ed eccezioni contengono dati sensibili, almeno parti del codice sorgente, ma a volte (ad es. PDOExceptions) anche nomi utente e password.
  • Errori di configurazione di Apache. Apache è una cosa potente, piena di funzioni oscure e alcune di esse hanno implicazioni sulla sicurezza.

Oltre a evitare queste trappole, dovresti mettere solo i file sotto la root del documento che devono essere chiamati direttamente; qualsiasi include, file di dati, file di configurazione, librerie, ecc., andare nelle directory al di fuori della root del documento.

    
risposta data 01.12.2012 - 01:14
fonte

Leggi altre domande sui tag