Insicurezza di configurazione PHP comune?

10

Lavoro con l'amministrazione dei sistemi in un'università e mi sono imbattuto in qualcosa che è probabilmente comune, ma è stato piuttosto scioccante per me.

Tutte le directory public_html e le aree web sono archiviate su afs, con permessi di lettura per i server web. Dato che agli utenti è permesso avere script php nel loro public_html, ciò significa che possono accedere ai file degli altri da php (e dai file web principali!).

Questo non solo rende completamente inutile qualsiasi protezione con password .htaccess, ma consente anche agli utenti di leggere file sorgente php contenenti password del database mysql e informazioni sensibili simili. O se scoprono che altre persone hanno directory in cui i server Web hanno accesso in scrittura (ad es. Per registri personali o per salvare i dati dei moduli inviati) possono archiviare i file in tali account.

Un semplice esempio:

<?
  header("Content-type: text/plain");
  print file_get_contents("/afs/example.com/home/smith/public_html/.htpasswd"); 
?>

È un problema comune? E come lo risolvi in genere?

AGGIORNARE:

Grazie per l'input. Sfortunatamente, sembra che non ci sia una risposta semplice. In un grande ambiente condiviso come questo, probabilmente agli utenti non dovrebbe essere data molta scelta. L'approccio migliore che mi viene in mente è di impostare "open_basedir" nella configurazione principale per tutte le directory "public_html", eseguire suphp e consentire solo php pulito (niente script cgi, comandi esterni con backtick ecc.).

Cambiare la politica in questo modo, però, romperebbe molte cose e probabilmente renderebbe gli utenti afferrare i loro forconi e inseguirci ... Ne discuterò con i miei colleghi e aggiornerò qui se prendiamo una decisione su come cambiare l'installazione.

apache-2.2 security php

— Pontus
fonte

Questa è una domanda interessante Sono sicuro sui principali provider di hosting condiviso (ad esempio DreamHost), questo non è possibile. Ma sarei interessato a come proteggono da questo. suphp, come cstama menzionato, sembra una buona soluzione, ma è questo che usano la maggior parte dei provider di hosting?

— Lèse majesté,

1

Ho usato la open_basedirsoluzione di seguito sui sistemi di hosting condiviso di produzione, ma abbiamo diviso tutti nel proprio vhost - Non sono sicuro che funzioni per singole directory ...

— voretaq7,

8

Si può usare suphp che esegue lo script php con l'uid del suo proprietario.

http://www.suphp.org

— cstamas
fonte

Questo probabilmente non risolverà il problema sopra riportato (almeno in un ambiente di hosting condiviso. I file .htpasswd sono generalmente di proprietà dell'utente che possiede il sito e il gruppo (apache) o il mondo (perché gli utenti non conoscono / si preoccupano della sicurezza) leggibili, quindi anche con suphp sarebbero in grado di leggere quei file)

— voretaq7,

@ voretaq7: è possibile applicare diverse altre restrizioni. Per quanto ricordo, puoi persino negare l'accesso ai file che non possiedi. Quindi questo esclude l'attacco sopra.

— cstamas,

So che puoi limitare le autorizzazioni sui file ("Impossibile scrivere per gruppo / altro / chiunque"), ma non conosco un modo per bloccare le letture oltre le autorizzazioni di FS. Hanno check_vhost_docroot, ma AFAIK che si applica solo allo script in esecuzione (? Potrei sbagliarmi su questo)

— voretaq7

1

Non sono sicuro che suphp sia una buona soluzione in un ambiente come questo. Un utente può disporre di tutti i tipi di autorizzazioni che l'utente www non possiede. Un utente malintenzionato che ha individuato php potrebbe trovare chiavi ssh o keytab o modificare gli script di accesso degli utenti per creare backdoor. E le impostazioni "vhosts" non sono molto utili poiché le directory public_html sono disponibili tramite "/ ~ username" sull'host virtuale principale. Penso che forse gli script in public_html dovrebbero essere completamente disabilitati.

— Pontus,

4

Il mio suggerimento sarebbe quello di limitare l'accesso di PHP ai file (tramite open_basedire direttive simili, su base per-vhost): vuoi che gli utenti siano in grado di aprire / leggere / scrivere file sotto il loro webroot, e forse un livello sopra di esso (per scratch spazio), ma non una directory in cui verranno archiviati, ad esempio i htpasswdfile.

Una struttura di directory come:

/Client
    /auth
    /site
        /www_root
        /www_tmp

Soddisferebbe questo requisito: open_basedirpotrebbe essere indicato in /Client/sitemodo sicuro e htpasswdfile archiviati /Client/auth(con .htaccessfile o httpd.confmodificati per puntare invece alla posizione appropriata).
Questo impedisce ai tuoi clienti di aprire i file di qualcun altro, E come vantaggio gli utenti malintenzionati non possono leggere le cose in /Client/auth(o qualsiasi altra cosa sul tuo sistema, come /etc/passwd:-)

Vedi http://php.net/manual/en/ini.core.php per maggiori dettagli sull'implementazione di open_basedir e per-vhost.

— voretaq7
fonte

1

suphpcome notato da cstamas è anche una buona idea in un ambiente di hosting condiviso - C'è un piccolo overhead che lo configura, ma direi che il guadagno di sicurezza è valsa la pena. A corto di sandboxing di tutti i tuoi siti PHP in qualcosa come una prigione di FreeBSD o una macchina virtuale dedicata che è una delle maggiori vittorie di sicurezza.

— voretaq7,

"open_basedir" sembra essere un modo semplice per separare i file web principali da quelli dell'utente, a condizione che "public_html" sia servito attraverso il proprio host virtuale. Ma non protegge gli utenti l'uno dall'altro, poiché non hanno i loro host virtuali. Giusto?

— Pontus,

Non ho provato a impostare open_basedirall'interno di una direttiva <Directory>, ma penso che dovrebbe essere ammissibile ("provalo e vedi" - il peggio che può fare non funziona)

— voretaq7

1

Finora sembra che open_basedir sia quello che la maggior parte degli host web commerciali usa (di solito gli abbonati hanno i loro domini a pagamento o ricevono un sottodominio gratuito), ma per home page basate su directory come in un istituto accademico, suphp sembra essere la risposta migliore.

— Lèse majesté,

1

No, non è un problema comune perché la maggior parte degli host condivisi definirebbe una configurazione open_basedir nel file htaccess nella directory public_html di ciascun utente (o nel vhost se ogni utente ha il proprio vhost).

ad es. del file .htaccess:

# Assuming these are not set globally - its good practice to limit:
  php_flag magic_quotes_gpc off
  php_flag magic_quotes_runtime off
  php_flag register_globals off
  php_flag short_open_tag off
  php_value max_execution_time 60

# These set the user-specific paths
  php_value open_basedir /afs/example.com/home/smith:/usr/share/php/include
  php_value session.save_path /afs/example.com/home/smith/tmp
  php_value upload_tmp_dir /afs/example.com/home/smith/tmp

Ma assicurati di impostare le autorizzazioni giuste sul file .htaccess per impedire all'utente di modificare open_basedir (se provano a sovrascriverlo in subdir / .htaccess, non dovrebbe funzionare - ma probabilmente dovresti testarlo per assicurarti) .

HTH

C.

— symcbean
fonte

2

Ciò potrebbe aiutare a offrire una protezione iniziale di nuovi account. Ma il fatto che un utente non possa modificarlo può far venire la tentazione di rimuovere il file .htaccess (cosa che può fare poiché richiede solo l'accesso in scrittura alla directory public_html) e crearne uno proprio. L'aggiunta di un blocco "<Directory>" nella configurazione principale per ogni utente avrebbe funzionato, ma qui è ancora permesso di backtick comandi esterni da php, il che significa che open_basedir è facilmente aggirabile.

— Pontus,

@Pontus: buon punto sull'eliminazione del file (non sono sicuro che afs supporti l'attributo del file immutabile). Avrei dato +1 se avessi detto che l'esecuzione del webserver in prigione chroot avrebbe protetto da ogni sorta di vulnerabilità nell'esecuzione del programma.

— symcbean,

1

AFS ignora le autorizzazioni utente unix semplici. suPHP esegue un setuid prima di eseguire il programma php, ma ciò non fornisce al processo i token kerberos necessari per accedere ad AFS e limitarsi alle sue autorizzazioni. suPHP avrebbe dovuto essere modificato in qualche modo per ottenere quei token prima che potesse presentarsi al sistema AFS come quell'utente. Per quanto ne so, ciò non è stato fatto. (In effetti, ho trovato questa domanda quando ho cercato di vedere se qualcun altro lo avesse fatto.)

— Carlo B.
fonte