Le persone possono vedere il mio codice PHP se il rendering non riesce?

Question

Per poter eseguire PHP, ho dovuto abilitare Include su server web Apache. Nessuno può effettivamente vedere i miei file .php perché quando vengono recuperati dal server vengono resi e il client vede solo css/html/qualunque. Potrebbe solo evidenziare la mia novità con PHP.

È possibile che qualcuno interrompa la parte di rendering PHP del mio server in modo tale che i client possano vedere il mio codice .php quando richiedono una pagina?

E se questo è possibile, quali sono le misure preventive che posso adottare per garantire che il mio codice commerciale rimanga chiuso-source?

Anche in questo caso, questo potrebbe non essere una vera preoccupazione, ma mi piacerebbe sapere.

Answer 1

Ci sono due modi per questo accada:

1. Un server web configurato male che non esegue i file PHP. Questo non ha nulla a che fare con l'utente che genera un errore.
2. Esecuzione di funzioni di debug personalizzate che visualizzano errori con codice sullo schermo. Ad esempio, se si utilizza un framework di terze parti, può farlo automaticamente. L'utente potrebbe attivare qualcosa come questo.

Per aiutare a prevenire una di queste situazioni da problemi che causano:

• Non incorporare tutte le informazioni sensibili (ad esempio, le password) nei file di origine. Invece, includile da file che vivono al di fuori della web root. Quindi, se la tua fonte diventa visibile, nessuno sarà in grado di accedere a quei dati privati.

• Non visualizzare errori sullo schermo in produzione. Una password del database potrebbe apparire nell'eccezione generata.

• Assicurarsi di disabilitare le impostazioni di sviluppo/debug sulla produzione.

Answer 2

è possibile che qualcuno interrompa la parte di rendering PHP del mio server in modo tale che i client possano vedere il mio codice .php quando richiedono una pagina?

Questo può solo accadere quando il software del server web è stato configurato male di non processare .php file PHP. Non esiste alcun modo attivabile dall'utente per questo.

Le volte in cui questo è accaduto in passato su siti di alto profilo sono stati errori di configurazione e errori di battitura, come non aver correttamente aperto il tag , esponendo così il resto del codice in quel file.

Answer 3

No. Il codice PHP su una configurazione corretta non viene emesso automaticamente, a meno che non lo comunichi a. (I server erroneamente configurati che non sanno che dovrebbero eseguire i file .php probabilmente li stamperanno semplicemente come testo normale, in questo caso si verificherebbero problemi.)

Avresti solo bisogno di guardare questo in rari situazioni: ad esempio, quando si preleva il contenuto di un file e lo si invia all'utente, è possibile aggiungere un controllo per verificare che il file da recuperare non sia il codice PHP.

Ma in 99 dei 100 casi, non è necessario preoccuparsi di questo.

Answer 4

Questa non è una preoccupazione normale, ma scrivere/utilizzare PHP non sicuro (e altro software per quella materia) potrebbe lasciare dei buchi. Per PHP è importante utilizzare la programmazione difensiva come le query SQL di escape che includono qualsiasi input fornito dall'utente. Striscia di caratteri speciali (htmlentities() aiuta ma non è sempre sufficiente) ed è orientata alla sicurezza in ciò che consente alle persone di inserire direttamente gli effetti sul codice e sui database.

Answer 5

Direi che dipende molto dalla sicurezza del server stesso, se diventa vulnerabile agli attacchi c'è una possibilità che i codici possano essere compromessi.

Per quanto riguarda l'esposizione di PHP è anche sulle impostazioni del server, in passato ho visto persone chiedere perché vedono il loro codice PHP visualizzato sulla pagina web che è causato dall'uso del tag a mano breve <? che è di default non è generalmente abilitato ai server che causano la visualizzazione di PHP.

Answer 6

Come altri hanno detto, un web server mal configurato che tratta i file .php come testo normale sarà lieto di servire il vostro codice sorgente.

Oggigiorno la maggior parte dei framework (sia pubblici che interni), tuttavia, conserva pochissimo codice php in un'area accessibile dal Web. In genere, esiste un singolo file index.php nella root del documento, che include e chiama il codice in altri file che si trovano al di fuori della radice del documento.

Di solito, avrete qualcosa di simile:

/path/to/proj/   <-- your project root 
/path/to/proj/application <-- holds most of your appication code 
/path/to/proj/lib   <-- third-party libraries go here 
/path/to/proj/public  <-- your web server uses this as the document root. 
/path/to/proj/public/index.php <-- single point of entry into your applicaiton. all requests are routed through here. 
/path/to/proj/public/images  <-- static resources, like images, also live under the docroot. 

regole di riscrittura sono tipicamente utilizzati per marshall eventuali richieste attraverso un file index.php pubblico.

Con una configurazione come questa, se il tuo server web dovesse essere configurato in modo errato in un modo che provocherebbe la trasmissione del tuo codice, verrai coperto. L'unica perdita sarebbe il tuo file index.php, che è probabilmente un paio di istruzioni include/require e una singola funzione/chiamata al metodo. Niente di sensibile.

Guardare lo standard Zend Framework o Symfony (o qualsiasi framework, in realtà), il layout del file, per un'immagine più chiara.