it-swarm-eu.dev

Quali sono i rischi per la sicurezza nel consentire a qualcuno di caricare PHP?

Diciamo che un partner vuole caricare uno PHP sul mio server Apache. Che tipo di caos potrebbe essere causato da questo?

Quali PHP pongono minacce? Se questi PHP sono completamente disabilitati, consentirebbe di inserire PHP sui miei server allora essere al sicuro?

Questi sono alcuni dei parametri PHP che conosco e che rappresentano un difetto di sicurezza. Quali altri ci sono che non sono sicuri?

Scrittura sul server:

  1. fwrite

  2. file_get_contents

  3. FILE_APPEND

Apertura di file sul server:

  1. fopen

  2. file_get_contents

  3. includere

  4. fread

  5. url_get_contents

  6. curl_init

  7. curl_setopt

Eliminazione di file:

  1. unlink
  2. non settato

Ci sono altri difetti di sicurezza che dovrei pensare prima di consentire ai partner di aggiungere file .php sul mio server? Immagino che potrebbero essercene molti di cui non sono a conoscenza.

Sono anche preoccupato per gli script di loop che potrebbero esaurire tutti i miei RAM e CPU, attacchi di accesso backdoor, malware e simili. Esistono misure che posso prendere per impedire che e altro ancora sta succedendo?

Se ci sono Javascript, JQuery o altre lingue incorporate nello PHP, sono anche quelle pericolose? E che tipo di parametri in altre lingue dovrei disabilitare per proteggere il mio server?

In che modo siti Web come jsfiddle e codepen mantengono i loro siti sicuri, consentendo alle persone di pubblicare il proprio codice?

27
Michael d

È molto pericoloso, perché stai permettendo a qualcuno di caricare PHP con codice sconosciuto e intenzioni sconosciute, quindi se hai bisogno di questa funzionalità come parte del tuo sito web, dovresti rafforzare il tuo server, per esempio:

  • Impostare una sola directory per caricare PHP dagli utenti, è necessario applicare le autorizzazioni utente corrette (lettura, scrittura o esecuzione) per questa directory, ricordare di creare un utente specifico per questa directory, non utilizzare root utente.
  • È possibile creare un file .htaccess per la directory, quindi è possibile configurare impostazioni specifiche per quella directory ( Configurazione del file .htaccess ).
  • Convalida l'utente di input, anche se dovresti impostare un formato e una dimensione del nome specifici per PHP, se un file PHP non corrisponde a quel formato o al suo la dimensione è maggiore di quella consentita, quindi l'applicazione non dovrebbe consentire all'utente di caricare quel file.
  • Utilizzare la canonicalizzazione prima di utilizzare le funzioni dei file, ad esempio: realpath , basename . Questo ti aiuta a evitare l'attacco trasversale del percorso.
  • Dovresti disabilitare PHP funzioni ad alto rischio, ad esempio: exec, Shell_exec. Puoi farlo attraverso il file php.ini, ad esempio, puoi aggiungere la seguente riga aiuta a disabilitare le funzioni per il sistema operativo esecuzione del comando e gestione delle impostazioni:

    disable_functions =exec,passthru,Shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
    

    La seguente riga aiuta a disabilitare le funzioni per includere o aprire file da fonti esterne:

    allow_url_fopen=Off
    allow_url_include=Off
    

Documentazione ufficiale php.ini file

Quelle sono alcune raccomandazioni di base. Dovresti analizzare la tua applicazione web e le tue esigenze per configurare le giuste impostazioni per il tuo server e la tua applicazione web.

Spero che questa informazione ti sia utile.

33
hmrojas.p

Se permetti a qualcuno di caricare ed eseguire uno PHP sul tuo server, dai effettivamente a questa persona il diritto di fare tutto ciò che potrebbe fare, se avesse accesso ssh con username/password per elabora lo PHP viene eseguito come.

Pertanto, se la persona in questione eseguisse lo script tramite Apache, la persona potrebbe fare qualsiasi cosa l'utente Apache sul proprio server possa fare.

Come ulteriore rischio, questa persona potrebbe usare l'accesso dato per provare l'escalation dei privilegi, qualcosa che probabilmente infrangerebbe l'accordo legale che hai con loro (hai un accordo legale, vero?).

29
Jacco

Per me sembra che stai per spararti al piede. Consentire alle persone di cui non ti fidi di caricare ed eseguire PHP sul tuo server è estremamente pericoloso. Ecco alcune cose che un utente malintenzionato potrebbe provare:

  • Esegui comandi batch assumendo il tuo server web. Può quindi essere utilizzato come terreno di gestione temporanea per attaccare altri server all'interno della rete.
  • Leggi i file contenenti segreti, ad es. password, chiavi di crittografia, chiavi TLS, ecc.
  • Esegui attacchi XSS (utilizzando JavaScript) per rubare i cookie di sessione o altre credenziali dai tuoi utenti. Ciò presuppone che i file caricati vengano eseguiti nello stesso dominio o sottodominio di altre applicazioni.

L'elenco potrebbe continuare all'infinito. Esistono modi per provare a bloccare questi attacchi ( hmrojas.p ha alcuni suggerimenti), ma non è una cosa semplice da fare. Le funzioni della lista nera sono un inizio, ma la lista nera non è mai più di una difesa parziale. Anche per il meglio degli esperti, contenente qualcuno che può eseguire PHP è una sfida.

Alla fine, se non ti fidi della persona che ha scritto il codice, dovrai controllare attentamente e manualmente il codice per assicurarti che sia benigno. Ciò richiede tempo e fatica e non è compatibile con il caricamento diretto dei file.

A volte, l'unica mossa vincente è non giocare. Direi che questo è uno di questi casi.

25
Anders

Mentre ci sono siti che ti permettono di eseguire PHP su richiesta (es. v4l ), limitano fortemente ciò che puoi fare e passa attraverso alcuni dei principali cerchi per farlo in sicurezza

Uso una configurazione in cui gli script vengono eseguiti in una piccola macchina virtuale. Per motivi di sicurezza questa macchina non ha rete e solo un filesystem minimo. Gli script sono eseguiti da un demone (scritto in Golang) e i risultati (con statistiche) sono riportati in un database PostgreSQL. Tutti i risultati vengono archiviati e utilizzati per fornire le medie per la panoramica delle prestazioni.

Non permetterei agli utenti di caricare PHP in un ambiente live. Una volta avevamo un tirocinante che stava scrivendo uno script per il caricamento delle immagini. Tranne che si era dimenticato di convalidare qualcosa sul file che stava accettando. Qualcuno ha caricato un PHP dalla Turchia e ha tentato di prenderne il controllo (se ne sarebbe andato anche se non fosse stato per altri sforzi di sicurezza sul server).

17
Machavity

PHP ha molte funzioni per disabilitare funzionalità e limitare determinate azioni in modo che possa essere utilizzato in scenari di hosting condiviso. Quindi è molto più sicuro consentire alle persone di caricare script php rispetto agli script Perl, quando il tuo server web e l'istanza php sono configurati correttamente.

Quindi voglio affrontare un'altra cosa oltre alla sicurezza di urlopen e simili: Stai permettendo alle persone di gestire siti interattivi.

Le conseguenze sono pericolose indipendentemente dalla quantità di rete o disco IO che possono fare, perché possono ad esempio configurare un sito di phishing, che può riflettersi negativamente sul dominio e sulla reputazione IP.

Quindi non finisci in una lista nera a causa delle e-mail di spam in quanto vengono bloccate impedendo a php di inviare e-mail, ma probabilmente perché stai eseguendo uno script che phishing per gli accessi Facebook dell'utente.

5
allo

Si menziona un server Apache, ma non ha o meno PHP installato.

Entrambi i software possono essere utilizzati/installati senza l'altro.

Entrambi i software sono disponibili per più sistemi operativi .. non hai menzionato quale è in gioco qui.

Nel caso in cui PHP è installato sul server:

Il rischio è che, se l'account utente PHP finisce sotto, abbia diritti amministrativi sulla macchina, può fare qualsiasi cosa nella libreria PHP.

Se tale account non ha diritti amministrativi, ciò limita ciò che può fare.

Alcuni sistemi operativi hanno exploit rilevabili/noti che consentono agli account non amministrativi di "ottenere" diritti amministrativi. Questi sono noti come exploit di escalation di privilegi. Se ne viene utilizzato uno, quindi di nuovo .. possono fare qualsiasi cosa nella libreria PHP.

Nel caso in cui PHP non è installato sul server:

C'è poco o nessun rischio. A PHP è solo un file di istruzioni che PHP interpreta e agisce. Non è più dannoso di un file di testo con una ricetta per lo stufato.

2
Miles Prower

Non è possibile "proteggerlo" in alcun modo. Qualsiasi quantità di consentire a qualcuno/chiunque di eseguire il codice a piacimento su un sistema può portare al completo rilevamento del sistema, sia intrinsecamente dovuto all'esecuzione di tutte le istruzioni a causa di difetti nel sistema che sta cercando di impedire l'utilizzo di determinate funzioni.

Anche un linguaggio di scripting in una jail/chroot/container come utente dedicato può in ultima analisi sfruttare le vulnerabilità (esistenti/nuove) che consentono l'accesso completo alla radice e altro (ad esempio l'accesso al firmware). Questo è ciò che i provider di hosting condiviso devono affrontare tutto il giorno. La maggior parte della prevenzione e del fissaggio deriva da due cose:

  1. Legale; elencare ciò che possono e non possono fare in anticipo in un contratto

  2. Processi; disporre di esuberi e schemi di risanamento fanno fronte a violazioni/perdite

1
John Keates