L'accesso pubblico a specifici nomi di file e tipi deve essere negato preventivamente?

2

È una buona idea disabilitare preventivamente l'accesso (pubblico) a determinati tipi di file (per estensione) e / o ai nomi di file:

  1. nella configurazione del server (nel caso di un server di hosting condiviso) o
  2. come regola di riscrittura per un sito Web o un'applicazione web?

Ad esempio nomi di file come:

  1. readme
  2. changelog
  3. debug
  4. errori
  5. phpinfo

O le seguenti estensioni di file in combinazione con i nomi di file sopra: php , log , html , htm , txt , doc , docx , rtf e possibilmente di più e% estensione del filewithout any.

E negando l'accesso a estensioni di file specifiche come: svn , git , sh , bat , cmd , sql , ini , config , conf , bak , backup e old .

È una buona idea farlo? Al fine di prevenire la perdita di informazioni quando questi file vengono spostati (accidentalmente) in una cartella pubblica.

    
posta Bob Ortiz 21.06.2016 - 11:36
fonte

3 risposte

1

Is it a good idea to preventively disable (public) access to certain filetypes (by extension) and/or by filenames?

Assolutamente! In effetti, tutti gli accessi dovrebbero essere negati e consentire solo le note buone richieste. Questo è altrimenti noto come "Default Deny" o "Whitelisting".

Marcus Ranum ha alcuni punti importanti in Le sei idee più stupide in materia di sicurezza informatica . Sebbene strettamente correlati, i primi due si applicano direttamente alla tua domanda.

  • 1) Permesso predefinito - Questo è il tuo approccio attuale in quanto tutte le richieste sono consentite tranne i pochi nomi file / estensioni / ecc. che sono esplicitamente negati. È molto più facile e molto più sicuro bloccare tutto e consentire solo le richieste valide conosciute. Sono disponibili molti spider del sito Web che eseguiranno la scansione di tutti i collegamenti disponibili. Una volta che viene prodotto un elenco di URL, puoi esaminarlo e scegliere quelli a cui solo gli utenti finali dovrebbero accedere. Questa è anche un'opportunità per garantire che il sito Web non stia inavvertitamente inserendo pagine con restrizioni (ad esempio, solo l'amministratore).

  • 2) Enumerazione di Badness - È molto più semplice implementare un "Default Deny" e solo consentire a richieste con buone conoscenze di avere regole per ogni possibile cattiva richiesta. Se il tuo sito web sta eseguendo PHP, non vuoi gestire le regole per bloccare le richieste di Ruby, Java, ASP, ecc. Non solo è un lavoro inutile, gestire un elenco così grande è incline a errori di configurazione, soprattutto errori di battitura.

Un effetto collaterale positivo è che probabilmente vedrai un aumento delle prestazioni, poiché solo le richieste più conosciute potranno attraversare l'intero stack.

    
risposta data 27.06.2016 - 00:10
fonte
3

Nei server Web che eseguo, rifiuto l'accesso a qualsiasi tipo di file di registro del server e file sensibili che contengono dettagli di configurazione di app Web come Word%'swp-config.php file

Tuttavia, se stai eseguendo un sito web, negando l'accesso a PHP, HTML, CSS, oltre ad altri tipi di file renderebbe il tuo sito Web inutilizzabile poiché i browser devono accedere a tali file per visualizzare correttamente il tuo sito web.

Inoltre, esaminerei correttamente le autorizzazioni dei file di impostazione per i tuoi file per garantire che solo gli utenti appropriati abbiano accesso alla vista , modificali e spostali.

Infine, consiglierei di inserire i tipi di file nella whitelist invece di inserirli nella blacklist perché generalmente ci sarà meno spazio per errori e non occuperà molto spazio nel file .htaccess o nei blocchi del server.

Tipi di file nella white list in Apache

Tipi di file nella lista bianca in Nginx

    
risposta data 24.06.2016 - 02:09
fonte
1

Supponendo che tu stia usando un linguaggio e un'ampiezza decenti framework, gli unici URL accessibili sono i percorsi che hai definito. Tutto il resto dovrebbe ottenere 404 per impostazione predefinita, tranne forse i file statici non sensibili in una directory specifica.

Qualunque cosa sensibile dovrebbe essere fuori dalla portata del server web e dovrebbe essere trasmessa solo dall'applicazione se dovesse scegliere di farlo.

    
risposta data 26.06.2016 - 03:25
fonte