In Apache, perché il proprietario di dati www di una directory di applicazioni Web è più sicuro di 777 ricorsivo?

Question

In Apache, perché il proprietario di dati www di una directory di applicazioni Web è più sicuro di 777 ricorsivo?

#1 da (2 voti)

0

Ho Ubuntu 16.04 LTS e sto eseguendo la mia applicazione web php tramite Apache (php-fpm). Sono poco preoccupato per i file e le autorizzazioni di directory. Molti link suggeriscono che dovrei mantenere il proprietario www-data o apache (dipende dal mio utente del server web) per la mia directory di applicazioni web. Tutte le directory dovrebbero avere 755 e tutti i file dovrebbero avere 644. I file con 644, Directory con 755 e proprietario della directory dell'applicazione web (ricorsiva) sono root o ubuntu, questo mi sembra buono ma la mia applicazione yii non è in grado di creare file in runtime e risorse quindi non sono in grado di accedere come gli utenti non sono in grado di caricare file nelle directory di caricamento.

Se fornisco la directory 777 ricorsiva per i caricamenti, inizia a funzionare correttamente ma un intruso può caricare un file dannoso al suo interno e tutti i file sono 777, quindi può semplicemente rimuoverli tutti.

Se metto solo 777 nella cartella, non i file, quindi gli utenti non sono in grado di modificare il file caricato, cioè una delle funzionalità, quindi la funzionalità non funziona, per motivi di sicurezza va bene.

Se divento proprietario di 755 dati www-data dei caricamenti ricorsivi, vuol dire che l'utente può caricare file, modificare file perché www-data ha letto i permessi di scrittura per la directory e il contenuto ma l'intruso ha anche la stessa autorizzazione per il suo file dannoso . In questo caso, può anche rimuovere tutti i file.

Sommario Se tengo 755 per tutti i file e 644 per tutti i file con proprietario www-data della directory dell'applicazione web ricorsivamente. Funziona tutto bene, non ho bisogno di dare 777 a upload, runtime o risorse, può creare file all'interno di queste directory quando l'utente usa l'applicazione web, ma un intruso può anche creare file php in queste directory con il proprietario di www-data che significa, ha anche il pieno permesso di modificare tutti i file di tutte le directory. Non voglio gestirlo in Apache per rendere proibita l'esecuzione di file php all'interno dei caricamenti. Per diverse applicazioni Web, questo nome è diverso e molte applicazioni utilizzano più directory per il caricamento. Non voglio negare tutto per i file php delle cartelle di upload. Ci dovrebbero essere le autorizzazioni corrette che potrebbero gestire meglio questo.

Si prega di suggerire.

permissions apache

posta Derek 21.10.2018 - 17:58

fonte

1 risposta

Leggi altre domande sui tag permissions apache

Quali tipi di applicazioni Web richiedono il filtraggio dinamico dei pacchetti o l'ispezione approfondita dei pacchetti Converti ntlm in aes256 in sekurlsa :: pth

score 2 · Answer 1

I rischi di una cartella con 777 privilegi e da una cartella con 755 privilegi di www-data sono leggermente diversi. Nel caso della cartella 777, se un utente malintenzionato è in grado di ottenere il controllo di qualsiasi utente sul server, sarà in grado di modificare ed eliminare i file caricati. Nel caso dei 755 privilegi, se sono in grado di compromettere l'utente www-data (o qualsiasi utente in quel gruppo), possono comunque modificare ed eliminare i file caricati, ma se compromettono qualsiasi altro utente, possono solo leggere il contenuto dei file, senza poter apportare modifiche.

Se tutti gli utenti del sistema si trovano nel gruppo www-data , non c'è alcuna differenza, ma di solito non è così. Ad esempio, se il server esegue sia un database che il sito Web, il DBMS verrà generalmente eseguito come utente in un gruppo diverso. In questo caso, un difetto nel DBMS che consente l'esecuzione del codice non consentirebbe a un utente malintenzionato di influenzare direttamente i file caricati, a meno che non possano estendere il proprio privilegio a un membro del gruppo www-data o dell'utente root.

Per le autorizzazioni a grana fine, esamina le opzioni come Access Control Lists (ACL), che può consentire regole più specifiche rispetto all'approccio base proprietario-gruppo-tutti, o SELinux, che può implementare il controllo di accesso obbligatorio a file e cartelle, ad esempio, si può dire "solo i processi con un particolare flag possono scrivere in questa cartella". In entrambi i casi, è molto facile spararti nel piede con - prova attentamente prima di applicarlo a un server live!