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

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

• Imposta una sola directory per caricare file PHP dagli utenti, devi applicare le autorizzazioni utente corrette (lettura, scrittura o esecuzione) per questa directory, ricorda di creare un utente specifico per questa directory, non utilizzare l'utente root.
• È possibile creare un file .htaccess per la directory, quindi è possibile impostare impostazioni specifiche per tale directory ( Configurazione del file .htaccess ).
• Convalidare l'utente di input, anche se dovresti impostare un nome specifico e una dimensione massima per i file PHP, se un file PHP non corrisponde a quel formato o la sua dimensione è maggiore di quanto consentito allora l'applicazione non dovrebbe consentire all'utente per caricare quel file.
• Utilizzare la canonicalizzazione prima di utilizzare le funzioni dei file, ad esempio: realpath , basename . Questo ti aiuta ad evitare l'attacco di attraversamento del percorso.

• Devi disabilitare le funzioni PHP ad alto rischio, ad esempio: exec, shell_exec. È possibile farlo tramite il file php.ini, ad esempio, è possibile aggiungere la seguente riga per disabilitare le funzioni per l'esecuzione dei comandi del sistema operativo e la 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 del file php.ini

Questi sono alcuni consigli di base. Dovresti analizzare la tua applicazione web e le tue esigenze per impostare le giuste impostazioni per il tuo server e la tua applicazione web.

Spero che questa informazione ti aiuti.

Se permetti a qualcuno di caricare ed eseguire uno script PHP sul tuo server, concedi a questa persona il diritto di fare qualsiasi cosa lui o lei potrebbe fare, se avesse accesso ssh con nome utente / password per il processo in cui lo script PHP viene eseguito come .

Quindi, se la persona in questione eseguisse lo script tramite Apache, la persona potrebbe fare tutto ciò che l'utente Apache sul tuo server potrebbe fare.

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

A me sembra che tu stia per spararti ai piedi. Lasciare che persone che non si fidano di caricare ed eseguire PHP sul tuo server è estremamente pericoloso. Ecco alcune cose che un utente malintenzionato potrebbe provare:

• Esegui comandi batch prendendo il tuo server web. Può quindi essere utilizzato come piano di sosta per attaccare altri server dalla rete.
• Leggi i file contenenti segreti, ad es. password, chiavi di crittografia, chiavi TLS, ecc.
• Attacchi XSS (utilizzando JavaScript) per rubare cookie di sessione o altre credenziali dai tuoi utenti. Ciò presuppone che i file caricati vengano eseguiti nello stesso dominio o in un sottodominio delle altre applicazioni.

L'elenco potrebbe continuare all'infinito. Ci sono modi in cui puoi provare a bloccare questi attacchi ( hmrojas.p ha alcuni suggerimenti), ma non è semplice cose da fare. Le funzioni di lista nera sono un inizio, ma la lista nera non è mai più di una difesa parziale. Anche per i migliori esperti, contenere qualcuno che può eseguire PHP è una sfida.

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

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

Mentre ci sono siti che ti permettono di eseguire codice PHP su richiesta (es. 3v4l ), limitano severamente ciò che puoi fare e fai un salto attraverso alcuni importanti cerchi per farlo in modo sicuro

I use a setup where scripts are executed in a small virtual machine. For security reasons this machine has no network and only a minimal filesystem. Scripts are executed by a daemon (written in Golang) and results (with statistics) are reported to a PostgreSQL database. All results are stored and used to provide averages for the performance overview.

Non consentirei agli utenti di caricare script PHP in un ambiente live. Una volta avevamo uno stagista che stava scrivendo uno script di caricamento delle immagini. Tranne che ha dimenticato di convalidare qualsiasi cosa sul file che stava accettando. Qualcuno ha caricato uno script di malware PHP dalla Turchia e ha tentato di prenderlo in consegna (anche lui se l'sarebbe cavata se non fosse stato per altri sforzi di sicurezza sul server).

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

Quindi voglio parlare di un'altra cosa oltre alla sicurezza di urlopen e simili: Stai consentendo alle persone di eseguire siti interattivi.

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

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

Hai menzionato un server Apache, ma non ha installato PHP.

Ciascuno software può essere usato / installato senza l'altro.

Entrambi i software sono disponibili per più sistemi operativi. Non hai menzionato ciò che è in gioco qui.

Nel caso in cui PHP sia installato sul server:

Il rischio è che, se l'account utente PHP dovesse finire sotto, avere i diritti amministrativi sulla macchina, possono fare qualsiasi cosa nella libreria PHP.

Se quell'account non ha diritti amministrativi, ciò limita ciò che possono fare.

Alcuni sistemi operativi hanno exploit scoperti / conosciuti che consentono agli account non amministrativi di ottenere i diritti amministrativi. Questi sono noti come exploit di escalation di privilegi. Se ne viene usato uno, poi di nuovo .. possono fare qualsiasi cosa nella libreria PHP.

Nel caso in cui PHP non sia installato sul server:

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

Non è possibile per nulla "proteggere" questo. Qualsiasi quantità di consentire a qualcuno / a chiunque di eseguire il codice a piacimento su un sistema può portare al completo takeover del sistema, intrinsecamente dovuto all'esecuzione di tutte le istruzioni relative a difetti nel sistema che sta tentando di impedire l'utilizzo di alcune funzioni.

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

1. Legale; elenca ciò che possono e non possono fare in un contratto prima del tempo

2. Processo; avere licenziamenti e schemi di recupero in atto affrontare le violazioni / perdite

Sì, vorrete sandbox questo. Probabilmente il modo più semplice per farlo è con l'esecuzione in una VM o contenitore docker . Certo, quindi dovrai controllare la sicurezza intorno a ciò.