Frage

Wir haben eine Rails-Anwendung in Subversion, die wir mit Capistrano bereitstellen, haben jedoch festgestellt, dass wir auf die Dateien in „/.svn“ zugreifen können, was ein Sicherheitsrisiko darstellt.

Ich wollte wissen, wie man das am besten macht.Ein paar Ideen:

  • Globale Apache-Konfiguration, um den Zugriff zu verweigern
  • Hinzufügen von .htaccess-Dateien im öffentlichen Ordner und allen Unterordnern
  • Cap-Aufgabe, die die Berechtigungen ändert

Die Idee, die Ordner zu löschen oder den SVN-Export zu verwenden, gefällt mir nicht wirklich, da ich die „SVN-Informationen“ gerne behalten möchte.

War es hilfreich?

Lösung

Die beste Option ist Apache-Konfiguration zu verwenden.

Mit .htaccess oder globaler Konfiguration hängt in erster Linie auf, wenn Sie Ihren Server steuern.

Wenn Sie das tun, können Sie so etwas wie verwenden

<DirectoryMatch .*\.svn/.*>
    Deny From All
</DirectoryMatch>

Wenn Sie nicht, können Sie etwas ähnliches in .htaccess-Dateien mit Filesmatch tun

Andere Tipps

Eine andere Möglichkeit, die .svn-Dateien zu schützen, wäre eine Umleitung in der Apache-Konfiguration verwendet werden:

RedirectMatch 404 /\\.svn(/|$)

Also, anstatt sich ein 403 verboten (und Bereitstellung von Hinweisen wäre Angreifer) Sie einen 404 bekommen, das ist, was wir erwarten würden, wenn zufällig in Pfade eingeben.

Ich mag die Idee nicht von jeder Datei startig wit ein Punkt 404ing. Ich habe gerne einen selektiven Ansatz verwenden, entweder mit dem cvs Ich verwende in dem Projekt (SVN im Beispiel)

RedirectMatch 404 /\\.svn(/|$)

oder einen Haken alle cvs Systeme

RedirectMatch 404 /\\.(svn|git|hg|bzr|cvs)(/|$)

- veraltete Antwort folgt (siehe Kommentare) -

Ich kann Kommentare schreiben noch so ... Die Antwort von csexton ist falsch, weil ein Benutzer die .svn Ordner zugreifen können, aber alle Dateien innerhalb darauf zugreifen können! z.B. Sie können darauf zugreifen http://myserver.com/.svn/entries

Die richtige Regel ist

RedirectMatch 404 /\\.svn(/.*|$)

Ich denke, Riccardo Galli hat es richtig gemacht.Sogar Apache hatte bereits .svn als für mich verboten eingerichtet, aber .svn/entries war auf jeden Fall verfügbar ... und legte meinen SVN-Server, meine Portnummer, meine Benutzernamen usw. offen.

Ich denke tatsächlich, warum man .git nicht als vorbeugende Maßnahme einschränken sollte (sagen wir, Sie verwenden Git noch nicht, aber eines Tages werden Sie vielleicht nicht mehr über Verzeichniseinschränkungen nachdenken).

Und dann dachte ich, warum nicht alles einschränken, was sowieso verborgen bleiben sollte?Kann sich jemand ein Problem dabei vorstellen?

RedirectMatch 404 /\\..*(/.*|$)

Ich habe das „.*“ nach dem Anfangspunkt hinzugefügt – der einzige Unterschied zu Riccardo.Scheint 404 .svn, .git, .blah usw. zu sein.

Ich würde lieber den Zugriff auf alle Dot-Dateien verweigern (zB: .htaccess, Svn, .xxx, etc.), wie sie in der Regel nicht Webzugriff sein müssen

.

Hier ist die Regel, dies zu erreichen (bis Apache 2.2 im Lieferumfang enthalten):

<LocationMatch "\/\..*">
    Order allow,deny
    Deny from all
</LocationMatch>

(UPDATE) Oder Sie können die folgende (die in Apache funktioniert 2.2 und 2.4) verwendet werden:

# Deny access to dot-files, as 404 error
# (not giving hint about potential existence to the file)
RedirectMatch 404 ".*\/\..*"

Dieses:

RedirectMatch permanent .*\.(svn|git|hg|bzr|cvs)/.* /

kann auch verwendet werden, wenn Sie zurück an den Benutzer keinen Fehler senden möchten.

Es ist Umleitung nur auf der Website Rootpage zurück. Auch dies ist eine dauerhafte Umleitung, so dass die Roboter nicht versuchen, diese URL indizieren.

Ein RedirectMatch reagiert mit einem 404, was toll ist.

Wenn jedoch „Options + Indexes“ aktiviert sind, dann Benutzer noch in der Lage sein, das ‚.svn‘ Verzeichnis, aus dem übergeordneten Verzeichnis zu sehen.

Die Benutzer werden die directory-- nicht in der Lage sein zu betreten das ist, wo die ‚404 Not Found‘ kommen in. Aber sie in der Lage sein werden, das Verzeichnis und gibt Hinweise wären es Angreifer zu sehen.

Ich scheint mir, Apache conf sein sollte:

<Directory ~ "\.svn">
    Order allow,deny
    Deny from all
</Directory>

Ich bin nicht so gern RedirectMatch, so habe ich eine RewriteRule statt:

RewriteRule /\..*(/.*|$) - [R=404,L]

Der Bindestrich bedeutet „keine Substitution tun“. Ich konnte auch nicht herausfinden, warum in den obigen Beispielen, die Regex zwei Schrägstriche hatten:

/\\..*(/.*|$)

Also nahm ich ein und es funktioniert gut. Ich kann nicht herausfinden, warum Sie zwei dort verwenden würden. Jemand kümmert mich aufklären?

Apache Subversion FAQ ist sugesting diese Lösung:

# Disallow browsing of Subversion working copy administrative dirs.
<DirectoryMatch "^/.*/\.svn/">
    Order deny,allow
    Deny from all
</DirectoryMatch>

Quelle: https://subversion.apache.org/faq.html# Website-auto-Update

RedirectMatch wie andere Richtlinien von mod_alias Groß- und Kleinschreibung auch auf Groß- und Kleinschreibung Dateisysteme (siehe mod_alias Dokumentation ). So sind die Antworten oben über passende und Sperrdateien aller Versionskontrollsysteme sind nicht korrekt.

Anstelle von

RedirectMatch 404 /\\.(svn|git|hg|bzr|cvs)(/|$)

oder

RedirectMatch permanent .*\.(svn|git|hg|bzr|cvs)/.* /

so etwas wie dies erforderlich ist,

RedirectMatch 404 "(?i)/\.?(cvs|svn|git|hg|bzr)"

wirklich alles zu blockieren, weil

  • CVS-Verzeichnisse sind in Großbuchstaben; und
  • beginnt nicht mit einem Punkt (.) Vor.

Ich hoffe, das hilft.

In .htaccess auf Ihrer Server-Konfigurationsdatei.

(1)

RewriteEngine on
RewriteRule "^(.*/)?\.git/" - [F,L]

Und (2)

RedirectMatch 404 /\.git

Dieses beide Verfahren in .htaccess Datei.

Es verbirgt sich eine Datei oder ein Verzeichnis, dessen Name beginnt mit .git wie .git Verzeichnis oder .gitignore Datei durch Rücksendung ein 404.

Erstellen Sie eine Zugriffsrechte Datei in Ihrem Subversion-Server-Installation.

z, wenn Sie Ordnerstruktur ist

/ svn

/svn/rights/svnauth.conf

eine Konfigurationsdatei erstellen und den Pfad der Datei in Ihrer Apache Subversion-Konfigurationsdatei eingeben, die Sie normalerweise in finden würden /etc/httpd/conf.d/subversion.conf

In Ihrer svnauth.conf Datei definiert die Rechte als:

Zugriffsrechte für Foo.com

[foo.com:/trunk/source]

dev1 = rw

dev2 = rw .....

Auf diese Weise kann die Zugriffsrechte aus einer einzigen Datei steuern und zu einer viel detaillierteren Ebene.

Für weitere Informationen lesen durch das svn rote Buch.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top