La funzione 'sistema' può comportare gravi minacce alla sicurezza su un server di hosting condiviso?

La chiamata di sistema PHP semplicemente inoltra i comandi alla riga di comando del sistema operativo. Se non si dispone dell'accesso da riga di comando al server che si sta affittando, è possibile vedere l'evidente preoccupazione di consentire tale comando, poiché ora come sviluppatore hai accesso al prompt dei comandi.

Tuttavia, anche se si dispone dell'accesso alla riga di comando, l'incorporazione della chiamata "di sistema" nel codice PHP può fare ancora più danni, poiché espone la linea di comando a qualsiasi insicurezza che la tua applicazione web possa avere. Supponiamo che io sia in grado di effettuare un'iniezione o un attacco XSS sulla tua applicazione web - se riesco a portare a termine un tale exploit, la probabilità che io possa inviare comandi direttamente al tuo server web è estremamente alta. Una volta che sono lì, ho completamente compromesso il tuo singolo server web.

Quindi, in un guscio di noce, sì, la chiamata di sistema può essere incredibilmente insicura senza input correttamente sterilizzati.

Un altro problema con le chiamate di sistema in un ambiente di hosting condiviso è che il processore PHP (apache / mod_php) è probabilmente eseguito da un utente con diverse / più autorizzazioni rispetto al tuo account (ad esempio, può legare l'ascolto ai messaggi TCP in entrata sulla porta 80, leggere i file di ogni utente host condiviso).

Quando si accede all'hosting condiviso e si ha accesso alla riga di comando, si è un utente con privilegi minimi (modificare solo i propri file e avviare / arrestare i lavoratori MPM di apache). Quindi si potrebbe potenzialmente usare system chiamato da php come una forma di escalation di privilegi (per dire di intercettare gli altri utenti sull'host condiviso).

Inoltre, è una pratica insicura usare chiamate eval / system nei programmi sicuri, specialmente quando il comando di eval / system viene costruito dall'elaborazione di stringhe che è facilmente iniettabile. Ad esempio, potresti avere un comando eval("mkdir $user_input"); , ma un utente malintenzionato potrebbe modificare $user_input="blank; rm -rf *" che potrebbe eventualmente eliminare alcuni file importanti. Le chiamate esistono per semplificare la vita quando la sicurezza non è un problema (ad esempio, è uno script locale eseguito da te solo sul tuo comptuer).

C'è quasi sempre un modo migliore per svolgere lo stesso compito. Forse la tua lingua ha comandi personalizzati che possono eseguire solo chiamate di sistema specifiche; ad esempio, python ha os.mkdir (non ho familiarità con PHP). O forse il linguaggio ha una forma più sicura di valutazione che non ha una forma iniettabile (analogo a come i parametri legati sconfiggono l'iniezione SQL). Ad esempio, python ha processo secondario dove subprocess.call(['mkdir', new_dir_name]) non è suscettibile all'iniezione di shell (anche con spazi all'interno di new_dir_name sarà comunque trattato come un singolo argomento di mkdir dalla shell).

Forse è necessario che un'operazione di file system complessa si verifichi ogni volta che un utente esegue un'azione. In tal caso, avrei impostato uno script che ascolta i lavori da aggiungere a una coda in un database e quindi esegue tali attività dal tuo account utente. Assicurati di disinfettare gli input che entrano nel tuo database (quindi le tue attività non sono iniettabili in shell).