Perché i server Web sono ubiquamente configurati inserendo nella blacklist file inaccessibili invece di inserire nella whitelist quelli accessibili?

Naviga le tue risposte
3

Prendi un sito PHP a caso. In sostanza, è garantito che il suo server web sia configurato come segue: serve qualsiasi file dalla radice del documento, ad eccezione di determinati file o percorsi che sono nella lista nera. Anche gli script sono resi eseguibili utilizzando un modello simile: tutti i file .php sono eseguibili dal server Web ad eccezione di quelli in blacklist.

ASP.NET è configurato allo stesso modo in IIS: * i file .aspx sono, per impostazione predefinita, eseguibili da qualsiasi directory, e si suppone che si debbano blacklist come una posizione pubblica "upload" per prevenire vulnerabilità.

Non conosco altri server Web, ma in IIS è possibile girarlo completamente, rimuovendo tutti i mapping del gestore e quindi autorizzando file / percorsi molto specifici. Dato un codebase ben strutturato, uno può avere solo due di questi mapping: una singola mappatura per un "/ public /" da servire da StaticFileHandler, e un'altra mappatura che mappa "/index.php" - e niente else - per FastCgiModule. Per ASP.NET, è un po 'più di lavoro, ma se questo fosse un obiettivo , gli strumenti potrebbero essere scritti nella whitelist di file .aspx durante la distribuzione, in modo che nessun altro file .aspx possa essere eseguito, non importa dove si trovano.

Permettere tutto e quindi provare a tappare i buchi è sicuramente uno dei "no-no" della "sicurezza 101". Perché è così onnipresente nelle configurazioni dei server Web?

    
posta RomanSt 24.09.2014 - 21:06
fonte

2 risposte

4

Poiché il contenuto del server web cambia frequentemente e sarebbe fastidioso dover aggiungere costantemente nuovi file a una lista bianca.

For ASP.NET, it's a bit more work, but if this were a goal, tools could be written to whitelist .aspx files during deployment, so that no other .aspx files could be executed, no matter where they are located.

Ma di solito non si distribuiscono i file .aspx, .php attraverso uno strumento. Li lasci semplicemente nella directory. Richiederebbe un enorme cambiamento nel modo in cui funzionano i linguaggi di scripting. Smetterebbero di essere linguaggi di scripting e diventeranno più simili a linguaggi compilati.

Allowing everything and then trying to plug the holes is surely one of the "security 101" no-no's. Why is it so ubiquitous in web server set-ups then?

L'inverso sarebbe basato sul presupposto che consentire il caricamento degli utenti sia un caso d'uso normale per tutti coloro che installano il webserver. Non è molto probabile che la maggior parte delle istanze di webserver consenta il caricamento degli utenti, poiché la maggior parte sono senza dubbio intranet aziendali o siti non interattivi che pubblicano semplicemente materiale per l'utente.

    
risposta data 24.09.2014 - 22:40
fonte
1

tl; dr: è costoso

funziona se hai

  • un waf che consente la whitelisting + modalità di apprendimento
  • generazione di whitelist automatica
  • cicli di implementazione automatizzati e un ambiente di test / controllo completo in grado di testare QUALSIASI nuova funzione e funzione
  • buoni test di regressione
  • ...
risposta data 25.09.2014 - 02:50
fonte

Leggi altre domande sui tag

wrapper di script Set-uid, shell (system) (3) e Bash Function Import from Environment Le password monouso resistono agli attacchi bruteforce? Alternativa immunitaria?