Calculer Girl
  1. Calculer Girl
  3. Sécurité: Est-il recommandé de nommer des dossiers sur le serveur difficiles à deviner?
Intereting Posts
erreur de dépassement de délai en appelant xxx.cloudapp.net dans la machine virtuelle Windows Azure. Terminaux configurés et apache installé, PHP Importation d’un jar Apache HttpClient plus récent dans Android Importer Matplotlib sans affichage Je veux consortingbuer au kernel Linux .htaccess Réécrire le dossier parent vers le sous-dossier Rewrite rules: oublier une chaîne de requête dans .htaccess Comprendre les fourches en C Comment désactiver mod_security et mod_security2 dans .htaccess Obtenir le nom de l’ordinateur client LAN dans une application Web basée sur un servlet comment faire apparaître screenfetch automatiquement chmod: Comment append récursivement des droits d’exécution uniquement aux fichiers qui ont déjà une autorisation d’exécution Comment apprendre à travailler efficacement avec Unix CLI Comment configurer Apache et LDAP pour permettre une deuxième tentative d’authentification? Drupal Multisite – Sous-répertoire, hébergement partagé Pas de stack ou de tas en faisant objdump

Sécurité: Est-il recommandé de nommer des dossiers sur le serveur difficiles à deviner?

Question de sécurité: Est-ce une bonne pratique de nommer les dossiers sur le serveur par des noms difficiles à deviner (plus de 8 symboles, pas un simple “admin” ou “services”)? Je m’interroge sur les dossiers qui contiennent non seulement des fichiers icons ou des fichiers .js ou des fichiers .css, mais des fichiers .php et qui sont protégés par un fichier .htaccess (refus de tous).

Non, la sécurité à travers l’obscurité ne l’est pas.

De plus, il est vraiment irritant pour quiconque utilise la machine via un shell, un ftp, etc.

Qu’est-ce que cela protégerait? Indépendamment des noms, l’access aux dossiers doit être géré par les mécanismes de sécurité normaux de la machine et / ou du réseau. S’ils le font, peu importe ce que vos artefacts sont nommés-Ur PwNeD.

La bonne pratique serait de garder vos fichiers PHP en dehors de la racine du document de votre serveur Web. Par exemple, si votre racine de document est / var / www, alors vous pourriez avoir un seul fichier index.php, et tout ce que fait ce fichier est de lancer votre application: 

set_include_path('/something/besides/var/www'); require_once 'foo.php'; require_once 'bar.php'; do_something();

De cette façon, votre serveur Web ne sait même pas que les fichiers PHP existent, et ne peut pas les servir même si vous avez un fichier .htaccess mal configuré.

C’est la sécurité par l’obscurité . Bien qu’il n’y ait pas de mal à le faire, cela ne donne rien en termes de sécurité.