Domanda:
Quali rischi per la sicurezza ci sono nel permettere a qualcuno di caricare script PHP?
Michael d
2018-03-21 17:58:33 UTC
view on stackexchange narkive permalink

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

Quali parametri PHP rappresentano una minaccia? Se quei parametri PHP sono completamente disabilitati, consentire l'inserimento di PHP sui miei server sarebbe sicuro?

Questi sono alcuni parametri PHP che so 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 dei file sul server:

  1. fopen

  2. file_get_contents

  3. include

  4. fread

  5. url_get_contents

  6. curl_init

  7. curl_setopt

Eliminazione di file:

  1. unlink
  2. unset

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

Sono anche preoccupato per gli script di loop che potrebbero utilizzare tutta la mia RAM e la CPU, attacchi di accesso backdoor, malware e simili. Esistono misure che posso adottare per evitare che tutto questo e altro accada?

Se nello script PHP sono incorporati Javascript, JQuery o altri linguaggi, sono pericolosi anche quelli? 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 protetti consentendo alle persone di pubblicare il proprio codice?

Una sandbox potrebbe aiutare.Vedi [C'è una sandbox PHP, qualcosa come JSFiddle sta a JS?] (Https://stackoverflow.com/q/4616159) e Google `PHP sandbox`.
Qual è il tuo caso d'uso?Vuoi che il loro PHP diventi parte del tuo sito?
Giusto per essere chiari, intendi eseguire il PHP?Non lasciare che le persone lo scarichino come codice?
Ho qualcuno che vorrebbe mettere un po 'di PHP sul mio sito, un po' come l'outsourcing.Hanno un buon codice.Vorrei solo sapere se esiste un modo per prevenire la catastrofe in caso di comportamento dannoso.Se avessi un elenco di comandi che potrei verificare, potrei rivedere il codice per assicurarmi che non ci sia nulla di pericoloso nascosto in esso.Il PHP è progettato per essere eseguito sul sito.E potrebbe contenere altre lingue come javascript, jquery, ajax, ecc.
Ciao @NeilSmithline, se eseguissi una sandbox PHP con qualcosa come Runkit_Sandbox, il PHP inviato sarebbe sicuro al 100%?O c'è ancora un modo per le persone di corrompere il server tramite sandbox?
Non sono un esperto di sandbox PHP, ma non credo che nessun sandbox offra il 100% di sicurezza.Ma ci provano.Quindi questa è una strategia a basso rischio, ma non a rischio zero.
Sembra che tu voglia che il codice venga effettivamente eseguito e fornisca una parte delle funzionalità del tuo sito, nel qual caso il sandboxing (anche se potresti garantirlo) non aiuterà poiché sta cercando di evitare proprio questo.Se questo è quel tipo di sviluppo collaborativo, lo affronteresti come parte del processo di distribuzione: è uno scenario diverso per fornire un mezzo alle persone per caricare il codice sul tuo sito ed eseguirlo
Anche con un sandbox perfetto, hai ancora potenziali abusi: cosa succede se il suo script utilizza un mucchio di CPU / memoria?Se hai abilitato l'accesso ai file o alla rete, può anche utilizzare tutte quelle risorse.
Le altre lingue saranno limitate a cose lato client come JavaScript, HTML, ecc.?O ci saranno anche cose come codice bash lì dentro?Inoltre, sei preoccupato per la sicurezza del tuo * utente * o solo per i tuoi siti?
Ripensandoci ulteriormente, penso che questa sia un'ottima cosa da chiedere, ma probabilmente dovrebbero esserci diverse domande correlate a causa dell'ampiezza e del livello di conoscenza iniziale (a meno che la risposta che stai cercando non sia semplicemente "ci sono un sacco dicose pericolose, non farlo senza ricerca ").Voto per chiudere come "troppo ampio", ma per favore interpretalo come un suggerimento per separare diverse domande più ristrette!ad esempio, "JavaScript in PHP è pericoloso", "quali tipi di cose pericolose può fare PHP su un server", "come disabilito (queste specifiche) cose pericolose in PHP" e così via.
Se la quantità di script caricati che ti aspetti è bassa, valuta la possibilità di porre il veto manualmente prima di renderli disponibili per l'esecuzione.
In un commento dici "_kind of like outsourcing_".Se questa persona _lavora_ per te (anche se solo su base ad-hoc), forse un valido contratto (con clausole "_non devi maliziosamente ..._") è un approccio alternativo / aggiuntivo.E se non ti fidi di lei / lui per _essere_ un dipendente (o equivalente) probabilmente non dovresti prendere il loro codice.
Risposta breve: terza guerra mondiale!
Non capisco perché stai facendo in modo che questa persona * carichi * file php sul tuo sito.Voglio dire: se vuole contribuire, allora dovrebbe fare richieste pull sul repository del tuo codice sorgente, in modo che tu possa esaminarle e accettarle / negarle ...
Otto risposte:
hmrojas.p
2018-03-21 20:47:14 UTC
view on stackexchange narkive permalink

È molto pericoloso, perché permetti 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 rafforzare il tuo server, ad esempio:

  • Imposta una sola directory per caricare file PHP dagli utenti, dovresti applicare le autorizzazioni utente corrette (lettura, scrittura o esecuzione) per questa directory, ricordati di creare un utente specifico per questa directory, non usare l'utente root.
  • Puoi creare un file .htaccess per la directory, quindi puoi impostare impostazioni specifiche per quella directory ( Configurazione del file .htaccess).
  • Convalida utente di input, anche tu dovresti impostare un formato 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 quella consentita, l'applicazione non dovrebbe consentire all'utente di caricare quel file.
  • Usa la canonicalizzazione prima di usare le funzioni file, ad esempio: realpath, basename. Questo ti aiuta a evitare l'attacco di attraversamento del percorso.
  • Dovresti disabilitare le funzioni PHP ad alto rischio, ad esempio: exec, shell_exec. Puoi farlo tramite il file php.ini, ad esempio, potresti aggiungere la seguente riga che aiuta a 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 riga seguente aiuta a disabilitare le funzioni per includere o aprire file da fonti esterne:

      allow_url_fopen = Offallow_url_include = Off  

Documentazione ufficiale 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 queste informazioni ti siano d'aiuto.

Imposta una sola directory per caricare i file PHP dagli utenti - Non dovrebbe essere una directory per utente.(Quindi ogni utente esterno ha una directory specifica e un utente locale specifico che esegue il codice da questa directory)
@Taemyr hai ragione, potrebbe essere un altro livello di sicurezza.
Il fatto che spendi oltre il 95% di questa risposta spiegando come provare a proteggere il server mi disturba immensamente.Dovrebbe essere il contrario: spendi il 95% della risposta scoraggiandolo e il 5% parlando di ciò che puoi fare.
@jpmc26 Ok, capisco il tuo punto perché è un argomento pericoloso, per questo ho detto "Se hai bisogno di questa funzionalità ..." prima di spiegare i miei consigli, ora quelli sono solo consigli, può decidere se seguirli o meno, anchequesto sito riguarda la sicurezza e come risolvere questo tipo di problemi, non evitarli, quindi gli utenti di questo sito sono professionisti e talvolta devono provare a risolvere i problemi prima di decidere di non continuare con una soluzione, per questi motivi ho considerato di darealcuni consigli, ma rispetto il tuo punto.
Non dimenticare il potenziale per rubare i cookie e aggirare le politiche di sicurezza relative al dominio, questo dovrà essere isolato su un dominio separato.Disabiliterei anche eval e create_function
@hmrojas.p "Questo sito riguarda la sicurezza e come risolvere questo tipo di problemi, non evitarli."Sono palesemente in disaccordo.Molto spesso l'unica risposta sensata in materia di sicurezza è: "Non farlo".E anche molto spesso, se devi chiederti se qualcosa di noto come pericoloso sia un rischio, semplicemente non hai le conoscenze per cercare di difenderti da esso, né il tempo e il denaro spesi per difenderti da esso sono un buon investimento.
Jacco
2018-03-21 19:21:14 UTC
view on stackexchange narkive permalink

Se consenti a qualcuno di caricare ed eseguire uno script PHP sul tuo server, concedi effettivamente a questa persona il diritto di fare tutto ciò che potrebbe fare, se avesse accesso ssh con nome utente / password per il processo lo script PHP viene eseguito come .

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

Come rischio aggiuntivo, questa persona potrebbe utilizzare l'accesso fornito per provare l'escalation dei privilegi, cosa che probabilmente romperebbe l'accordo legale che hai con loro (hai un accordo legale, vero?).

Se avessi un elenco di comandi che rappresentano un rischio per la sicurezza, potrei cercare quei comandi e rivedere il codice per assicurarmi che tutto sembri sicuro.O ci sono troppe cose che potrebbero andare storte che un elenco di comandi non è sufficiente?
PHP è un linguaggio di programmazione che consente la programmazione.Quindi se creo mycmd = 'c' + 'a' + 't' + '' '+'> '+' / '+' e '+' t '+' c '+' / '+ ... cosahai intenzione di grep per?Se divento più complesso ... La risposta semplice è che non esiste un modo semplice per eseguire codice non affidabile in modo sicuro.
@AdamShostack Grep per qualsiasi comando che interpreta una stringa come codice (es. Eval) e qualsiasi comando che passa una stringa al sistema operativo (es. Exec).La stringa mycmd da sola non è un pericolo.(Non che io raccomandi di consentire a estranei di caricare PHP, o di escludere una lista nera come protezione sufficiente se lo fai)
@Taemyr: PHP ha diversi modi per eseguire le funzioni dinamicamente, ad es.http://php.net/manual/en/functions.variable-functions.php
@Taemyr Non vedo l'ora di vederti fare una fortuna con il tuo fantastico nuovo strumento di analisi statica che lo rende sicuro.
@Taemyr, che potrebbe funzionare in un linguaggio sensato, ma stiamo parlando di PHP.
La lista nera di @Michaeld, non è una soluzione che funziona, ci sono * modo * troppe opzioni per aggirare le liste nere;questo è un fatto che è stato dimostrato troppe volte.La whitelist in questo caso funziona solo se puoi garantire di essere più intelligente della conoscenza combinata di tutte le persone che potrebbero utilizzare il tuo sistema.
@Taemyr https: // ideone.com / lBVfRW e no, non puoi semplicemente inserire nella lista nera `rkrp`, perché posso trovare infiniti modi per offuscarlo.
@gronostaj ti manca il punto del mio commento.Non mi interessa davvero come offuschi il contenuto di una variabile.Se non posso impedirti di eseguire il contenuto di una variabile che ho già perso.
@poizan42 affascinante.Chi pensava che fosse una buona idea?
@Taemyr * "Affascinante. Chi pensava che fosse una buona idea?" * Sono abbastanza sicuro che questo si possa dire della maggior parte di PHP in generale.
@Taemyr "Se non posso impedirti di eseguire il contenuto di una variabile che ho già perso" - credo che questo sia il punto che viene sottolineato.Non puoi, ci sono molti modi per ottenerlo in PHP ed è una parte fondamentale della struttura di metaprogrammazione.
@anaximander [Indeed] (https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/).(Un po 'datato ora, ma * ancora *.)
E per il [divertimento] (http://phpsadness.com/)!Sono tutti casi reali, errore di campo libero, testati, incontrati da un programmatore.
Solo per rafforzare il punto @gronostaj's, questo è un altro script php che utilizza exec per sborsare in un altro programma:
Anders
2018-03-22 14:51:09 UTC
view on stackexchange narkive permalink

A me sembra che tu stia per spararti a un piede. Permettere a 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 che assumono il controllo del tuo server web. Può quindi essere utilizzato come terreno di staging per attaccare altri server dalla tua rete.
  • Leggi i file contenenti segreti, ad es. password, chiavi di crittografia, chiavi TLS, ecc.
  • Esegui attacchi XSS (utilizzando JavaScript) per rubare cookie di sessione o altre credenziali dai tuoi utenti. Questo presuppone che i file caricati vengano eseguiti sullo stesso dominio o sottodominio di altre applicazioni.

L'elenco potrebbe continuare all'infinito. Ci sono modi per provare a bloccare questi attacchi ( hmrojas.p ha alcuni suggerimenti), ma non è una cosa semplice da fare. La funzione di blacklist è un inizio, ma la blacklist non è mai altro che una difesa parziale. Anche per i migliori esperti, contenere qualcuno in grado di 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 assicurarsi 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.

Penso di sapere cosa intendi qui, ma fidarsi del codice non lo rende sicuro.Mi dispiace essere pedante ma ho visto persone confondersi con cose come questa e fare l'opposto di quello che dovrebbero fare.
@JimmyJames Ovviamente la fiducia può essere mal riposta e ovviamente possono ancora esserci degli errori.Ma per definizione, se la tua fiducia è ben riposta, non ci sono problemi deliberati con il codice.Proverò a modificare per renderlo più chiaro.
Immagino che quello che sto cercando di dire sia che una relazione di fiducia dovrebbe essere considerata un rischio significativo.Non stai solo presumendo che la parte fidata non sarà nefasta, ma anche che abbia una sicurezza adeguata e protegga le proprie credenziali.Crea anche opportunità per terze parti di sovvertire quel rapporto di fiducia tramite difetti.La tua modifica sembra affrontare questo problema.
Machavity
2018-03-21 22:53:32 UTC
view on stackexchange narkive permalink

Sebbene ci siano siti che ti consentono di eseguire codice PHP su richiesta (ad esempio 3v4l), limitano fortemente ciò che puoi fare e salta attraverso alcuni importanti ostacoli 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 una rete e solo un filesystem minimo. Gli script vengono eseguiti da un demone (scritto in Golang) ei risultati (con le statistiche) vengono riportati a un database PostgreSQL. Tutti i risultati vengono memorizzati e utilizzati per fornire medie per la panoramica delle prestazioni.

Non consentirei agli utenti di caricare script PHP in un ambiente live. Una volta abbiamo avuto uno stagista che stava scrivendo uno script per il caricamento di immagini. Tranne che si è dimenticato di convalidare qualsiasi cosa sul file che stava accettando. Qualcuno ha caricato uno script di malware PHP dalla Turchia e ha tentato di prenderne il controllo (anche lui se la sarebbe cavata se non fosse stato per altri sforzi di sicurezza sul server).

allo
2018-03-22 17:39:10 UTC
view on stackexchange narkive permalink

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 piuttosto che script perl, quando il tuo server web e l'istanza php sono configurati correttamente.

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

Le conseguenze sono pericolose indipendentemente dalla quantità di rete o di IO del disco che possono creare, perché possono ad esempio configurare un sito di phishing, che può riflettono male sul tuo 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 posta, ma forse perché stai eseguendo uno script che phishing per i login di Facebook dell'utente.

Miles Prower
2018-03-23 00:47:05 UTC
view on stackexchange narkive permalink

Si parla di un server Apache, ma non se ha installato o meno PHP.

Ciascun software può essere utilizzato / installato senza l'altro.

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

Nel caso in cui PHP sia installato sul server:

Il rischio è che, dovrebbe l'account utente PHP finisce per funzionare, ha diritti amministrativi sulla macchina, possono fare qualsiasi cosa nella libreria PHP.

Se quell'account non ha diritti amministrativi, questo 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 dei privilegi. Se ne viene utilizzato uno, allora di nuovo ... possono fare qualsiasi cosa nella libreria PHP.

Nel caso in cui PHP non sia installato sul server:

Non c'è rischio minimo o nullo. tutti. Un file PHP è solo un file di testo di istruzioni che PHP interpreta e su cui agisce. Non è più dannoso di un file di testo con una ricetta per lo stufato.

John Keates
2018-03-23 05:34:45 UTC
view on stackexchange narkive permalink

Non è possibile "proteggerlo" in alcun modo. Qualsiasi quantità di consentire a qualcuno / chiunque di eseguire codice a piacimento su un sistema può portare al completo controllo 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 il pieno accesso root e altro (ad es. accesso al firmware). Questo è ciò che i provider di hosting condiviso devono affrontare tutto il giorno. La maggior parte della prevenzione e della riparazione deriva da due cose:

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

  2. Processo; disporre di licenziamenti e schemi di recupero in atto si occupano di violazioni / perdite

Marcin
2018-03-22 21:33:30 UTC
view on stackexchange narkive permalink

Sì, lo vorrai sandbox. Probabilmente il modo più semplice per farlo è con l'esecuzione in una VM o in un contenitore docker . Ovviamente, dovrai controllare la sicurezza attorno a questo.

No questo è sbagliato.È possibile sfuggire a un container Docker, ci sono exploit documentati per questo (alcuni più difficili di altri, ma eccoci qui).Considerando che il [daemon Docker viene eseguito come root] (https://docs.docker.com/engine/security/security/#docker-daemon-attack-surface), fidarsi di Docker per mantenere il codice dannoso contenuto sembra sconsiderato.Alla fine, imprigionare il codice non attendibile (anche tramite virtualizzazione) non ha molta importanza quando è necessario proteggere anche i servizi all'interno di quella stessa prigione.
@korrigan Quando dici "servizi [nella] stessa prigione" intendi servizi all'interno della stessa sandbox o altri servizi sulla stessa macchina host?La mia ipotesi è che non ci sia protezione per le cose che stanno insieme nella stessa sandbox.
Dal commento di OP: "Il PHP è destinato a funzionare sul sito".Sì, intendevo nella stessa sandbox (o prigione).La tua ipotesi è giusta a questo proposito.
@korrigan Ovviamente.Vorresti separare la pubblicazione dall'esecuzione qui.Per esempio.avere il server php in esecuzione nella VM e il resto del sito in esecuzione al di fuori di quella prigione.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...