Nous avons une application Rails dans Subversion que nous déployons avec Capistrano, mais nous avons remarqué que nous pouvons accéder aux fichiers dans '/.svn', ce qui pose un problème de sécurité.
Je voulais savoir quelle était la meilleure façon de procéder. Quelques idées:
Je n'aime pas trop l'idée de supprimer les dossiers ou d'utiliser svn export, car j'aimerais garder les informations sur svn.
La meilleure option consiste à utiliser la configuration Apache.
L'utilisation de htaccess ou de la configuration globale dépend principalement du contrôle de votre serveur.
Si vous le faites, vous pouvez utiliser quelque chose comme
<DirectoryMatch. * \. Svn/.*> Refuser de tout </ DirectoryMatch>
Si vous ne le faites pas, vous pouvez faire quelque chose de similaire dans les fichiers .htaccess avec FilesMatch
Une autre façon de protéger les fichiers .svn serait d'utiliser une redirection dans la configuration d'Apache:
RedirectMatch 404 /\\.svn(/|$)
Ainsi, au lieu d’obtenir un code 403 interdit (et de fournir des indices aux attaquants), vous obtenez un code 404, ce à quoi nous nous attendions lors de la saisie aléatoire de chemins.
Je n’aime pas l’idée de modifier chaque fichier avec un point .. Je choisirais une approche plus sélective, soit avec les cvs que j’utilise dans le projet (svn dans l’exemple).
RedirectMatch 404 /\\.svn(/|$)
ou attraper tous les systèmes CVS
RedirectMatch 404 /\\.(svn|git|hg|bzr|cvs)(/|$)
- réponse obsolète suit (voir commentaires) -
Je ne peux pas encore écrire de commentaires alors ....... La réponse de csexton est incorrecte, car un utilisateur ne peut pas accéder au dossier .svn, mais peut accéder à tous les fichiers qu'il contient! vous pouvez y accéder http://myserver.com/.svn/entries
La règle correcte est
RedirectMatch 404 /\\.svn(/.*|$)
Je pense que Riccardo Galli a bien compris. Même Apache avait déjà une configuration .svn interdite pour moi, mais .svn/entries était certainement disponible ... exposant mon serveur svn, mon numéro de port, mes noms d'utilisateurs, etc.
En fait, je pense que pourquoi ne pas limiter .git à titre de mesure préventive (par exemple, vous n’utilisez pas encore git, mais vous risquez un jour de ne pas penser aux restrictions de répertoires).
Et puis j'ai pensé, pourquoi ne pas limiter tout ce qui devrait être caché de toute façon? Quelqu'un peut-il concevoir un problème avec cela?
RedirectMatch 404 /\\..*(/.*|$)
J'ai ajouté le '. *' Après la période initiale - seule différence par rapport à Riccardo. Semble à 404 .svn, .git, .blah, etc.
Je préfère refuser l'accès à tous les fichiers de points (par exemple: .htaccess, .svn, .xxx, etc.), car ils n'ont normalement pas besoin d'être accessibles sur le Web.
Voici la règle pour y parvenir (jusqu'à Apache 2.2 inclus):
<LocationMatch "\/\..*">
Order allow,deny
Deny from all
</LocationMatch>
(UPDATE) Ou vous pouvez utiliser les éléments suivants (qui fonctionnent dans Apache 2.2 et 2.4):
# Deny access to dot-files, as 404 error
# (not giving hint about potential existence to the file)
RedirectMatch 404 ".*\/\..*"
Ce:
RedirectMatch permanent .*\.(svn|git|hg|bzr|cvs)/.* /
peut également être utilisé si vous ne souhaitez pas renvoyer d'erreur à l'utilisateur.
Il ne fait que rediriger vers la page racine du site. En outre, il s’agit d’une redirection permanente afin que les robots ne tentent pas de réindexer cette URL.
Un RedirectMatch répondra avec un 404, ce qui est génial.
Toutefois, si "Options + Index" est activé, les utilisateurs pourront toujours voir le répertoire ".svn" à partir du répertoire parent.
Les utilisateurs ne pourront pas entrer dans l'annuaire - c'est ici qu'intervient "404 Introuvables". Cependant, ils seront en mesure de voir l'annuaire et de fournir des indices sur les attaques.
RedirectMatch, comme les autres directives de mod_alias, est sensible à la casse, même sur des systèmes de fichiers ne respectant pas la casse (voir documentation mod_alias ). Par conséquent, les réponses ci-dessus concernant la correspondance et le blocage des fichiers de tous les systèmes de contrôle de version ne sont pas correctes.
Au lieu de
RedirectMatch 404 /\\.(svn|git|hg|bzr|cvs)(/|$)
ou
RedirectMatch permanent .*\.(svn|git|hg|bzr|cvs)/.* /
quelque chose comme ceci est nécessaire
RedirectMatch 404 "(?i)/\.?(cvs|svn|git|hg|bzr)"
vraiment bloquer tout, parce que
J'espère que ça aide.
Je n'aime pas tellement RedirectMatch, alors j'ai utilisé à la place une RewriteRule:
RewriteRule /\..*(/.*|$) - [R=404,L]
Le trait d'union signifie "ne faites aucune substitution". Je ne pouvais pas non plus comprendre pourquoi, dans les exemples ci-dessus, la regex avait deux barres obliques inverses:
/\\..*(/.*|$)
Alors j'en ai sorti un et ça marche bien. Je n'arrive pas à comprendre pourquoi vous en utiliseriez deux ici. Quelqu'un veut m'éclairer?
Apache Subversion FAQ propose cette solution:
# Disallow browsing of Subversion working copy administrative dirs.
<DirectoryMatch "^/.*/\.svn/">
Order deny,allow
Deny from all
</DirectoryMatch>
source: https://Subversion.Apache.org/faq.html#website-auto-update
Il me semble que Apache conf devrait être:
<Directory ~ "\.svn">
Order allow,deny
Deny from all
</Directory>
Dans .htaccess sur votre fichier de configuration du serveur.
(1)
RewriteEngine on
RewriteRule "^(.*/)?\.git/" - [F,L]
Et (2)
RedirectMatch 404 /\.git
Placez cette méthode dans le fichier .htaccess
.
Il masque tout fichier ou répertoire dont le nom commence par .git, comme le répertoire .git ou le fichier .gitignore, en renvoyant un 404