Dove posizionare i file PHP per sicurezza?

Inserisci i tuoi file pubblici in una cartella chiamata public e punta il nome del tuo dominio su questa cartella usando l'host virtuale apache, altri file non pubblici dovrebbero trovarsi in cartelle sopra la cartella pubblica e puoi fare riferimento ad essi con include_path ad esempio . Questo è il modo in cui sono strutturati molti framework.

Where to place PHP files for security?

Ricorda che non esiste il posto migliore dove archiviare i tuoi file in modo sicuro. La sicurezza dei tuoi file sensibili è solo il risultato di una combinazione di buone misure, come la prevenzione delle iniezioni di URL che potrebbero rivelare i tuoi file sensibili, che puoi prendere e discutere di seguito in breve.

My thought is it should follow the principle of least privilege, if those files don't need to be public then they shouldn't be. Why is this something that is not right at the start of PHP the right way?

La stessa domanda che potresti fare sul perché i firewall non sono raccomandati. Ma la risposta è perché l'articolo che hai scelto è destinato agli sviluppatori. Gli sviluppatori sono più preoccupati su come farlo funzionare di come renderlo sicuro . Guarda le sezioni discusse attraverso quell'articolo:

Introduzione (configurazione generale, versioni di PHP da scegliere ...), Guida allo stile del codice (Paradigmi di programmazione, Namespace, Libreria PHP standard, Xdebug ...), Gestione delle dipendenze, PEAR (installazione e così via), Procedure di codifica Iniezione delle dipendenze (un modello di progettazione software), Interagire con i database, Templatura ...

Come puoi intuire, questo è rivolto agli sviluppatori non a chi è preoccupato come te dagli aspetti di sicurezza di un'applicazione. L'unica sezione che parla un po 'di sicurezza è Security, e al suo interno potrebbe essere solo la sottosezione relativa all'hash delle password, il filtraggio dei dati e la disinfezione sono importanti ma ancora poco trattati.

Is there is a standard way of handling this?

L'articolo che hai collegato agli stati: Non esiste un modo canonico per usare PHP. La stessa cosa che possiamo dire: Non esiste un modo canonico per usare PHP in modo sicuro . Ciò detto, il principio del privilegio minimo che hai menzionato è d'obbligo e ci sono ancora buone pratiche di sicurezza che devi seguire perché solo una combinazione di questi principi tutti insieme può darti una garanzia migliore:

1. Difesa in profondità : devi risolvere il tuo problema in termini di livelli di sicurezza: installazione sicura di Apache, stile di codifica sicuro, firewall, file .htaccess efficaci ... Mentre alcuni argomentate che questo principio aggiunge complessità alla vostra applicazione e può portare nuovi rischi per la sicurezza, un'applicazione intelligente di questo principio può mantenere la vostra applicazione semplice ma sicura (ad esempio: hashing passord che consente l'accesso alle vostre cartelle è buono, ma salarli è meglio, peppering Inoltre, è anche meglio).

2. Specifica cartella e file lista bianca : anziché elencare cartelle e file a cui non è possibile accedere, è necessario autorizzare piuttosto l'accesso ai tuoi file / cartelle pubblici e rifiutare tutto il resto perché in questo modo non dimenticherai di proteggere alcuni file sensibili.

3. Minimo privilegio : i tuoi permessi di risorsa (i file nel tuo caso, ma puoi prendere in considerazione altri elementi) devono essere concessi al livello minimo per utenti del tuo sito web
4. Non fare molto affidamento su sicurezza attraverso l'oscurità per nascondere i tuoi file.
5. Riduci a icona la superficie di attacco della tua applicazione web
6. Rileva le intrusioni : registra le informazioni rilevanti per la sicurezza per identificare i rischi e proteggere la tua applicazione
7. Alcuni pensano che una rinomata società di hosting sia sufficiente come elemento per proteggere la propria applicazione, ma è comunque necessario proteggere la propria applicazione separatamente e indipendentemente dall'ambiente di hosting
8. Non fare affidamento solo sugli attori di terze parti per proteggere la tua applicazione

Fondamentalmente hai ragione: su un server che possiedi non è necessario posizionare i file PHP nella directory radice del documento. È necessario solo un punto di ingresso come un file index.php o qualsiasi altro file preso di mira dalle regole di riscrittura. Una volta che il server web passa la richiesta di elaborazione all'interprete PHP, non sei più legato da DocumentRoot percorso ma tramite l'interprete PHP open_basedir path (che non è impostato di default, permettendo all'interprete di PHP di accedere ai file ovunque sul tuo sistema).

Tuttavia, tale scenario richiede due prerequisiti:

• Possiedi il tuo server: la maggior parte degli ambienti condivisi impone una struttura di directory e una configurazione a livello di sistema che potrebbero non essere adatte a questo tipo di implementazione. Ad esempio potresti non avere accesso alle directory sopra il DocumentRoot interessato, o alcune restrizioni potrebbero essere applicate nella configurazione di PHP.

• L'applicazione web che intendi utilizzare lo supporta: Questo può essere spesso semplicemente riformulato in " Usa la tua applicazione web ". Infatti, la maggior parte dei progetti sono sviluppati in modo da renderli compatibili con la più ampia gamma possibile di utenti, e quindi impongono il minor numero possibile di prerequisiti.

  Pertanto, la maggior parte dei progetti considera l'applicazione web nel suo insieme da inserire in un'unica directory. È più facile da implementare e mantenere (sulla directory da aggiornare, nessun rischio di discrepanza del livello di aggiornamento tra più cartelle) e si adatta a qualsiasi situazione, indipendentemente dal fatto che stiate usando il vostro server o stiate noleggiando uno spazio di hosting condiviso.

  Alcuni progetti potrebbero tuttavia proporre l'impostazione che descrivi come un'opzione (usando un qualche tipo di parametro di configurazione include_path ), tuttavia questo potrebbe rendere il progetto più difficile da sviluppare e mantenere dal punto di vista dello sviluppatore (penso principalmente qui alla qualificazione test che avrebbero quindi più situazioni da prendere in considerazione) senza fornire alcun significativo vantaggio in termini di sicurezza.

Come detto tale misura non porterebbe comunque alcun vantaggio significativo in termini di sicurezza poiché su un server ben configurato il contenuto dei file PHP non verrà mai rivelato dal server Web: tali file verranno eseguiti dall'interprete PHP e mai inviati come file di testo non formattato . La minaccia principale è qualcuno che è in grado di eseguire codice sul proprio server (ad esempio installando una shell PHP) permettendogli di aggirare l'albero delle directory, ma in questo caso avere i file PHP all'esterno della directory DocumentRoot non sarà di alcun aiuto) .

Il principio del privilegio minimo rimane comunque vero, ma riguarderebbe solo il modo in cui il server web, l'interprete PHP e i file script PHP interagiscono tra loro. Ad esempio:

• Alcune implementazioni (un esempio classico come Nginx + PHP-FPM per esempio) ti permetteranno di usare diversi utenti per il web server e per l'interprete PHP, permettendoti di impostare liberamente quali file e risorse dovrebbero essere condivisi tra questi account o no.
• Puoi anche assicurarti che i file PHP siano leggibili e non scrivibili dall'utente che esegue l'interprete PHP, il La patch PHP Suhosin propone anche un parametro ( suhosin.executor. include.allow_writable_files ) impedendo l'esecuzione di qualsiasi file PHP non conforme a questo criterio,
• PHP offre anche il suddetto open_basedir che impedisce il PHP script di accedere a qualsiasi file che si trova al di fuori di alcune directory.
• Etc., ecc., ecc .: possono esserci molti altri modi per implementare il principio del minimo privilegio e proteggere la tua piattaforma di applicazioni web, alcune sono generiche, altre più specifiche per la tua piattaforma e applicazione.