Я хочу сохранить свой веб-сайт в управлении версиями (специально для Subversion) и использовать svn co для обновления, когда есть стабильные версии для обновления, но я беспокоюсь о безопасности этого, так как все .svn будут публичными, и они включают в себя все виды личных данных, не в последнюю очередь из которых - полный исходный код на мой сайт!
Есть ли что-нибудь, что я могу сделать, чтобы предотвратить это?
Две вещи:
Не используйте IfModule для функциональности, которую вы должны присутствовать. Это нормально делать для autoindex, потому что оно может отсутствовать и не имеет решающего значения для схемы. Но вы рассчитываете на то, что будете переписываться, чтобы защитить свой контент. Таким образом, лучше удалить директиву IfModule и позволить apache сообщать вам, когда переписать нет для вас, чтобы включить ее (или, по крайней мере, знать, что вы не будете защищены и сознательно комментируете строки)
Нет необходимости использовать переписывание там, если у вас есть доступ к основным файлам конфигурации, гораздо проще будет один из
<DirectoryMatch \.svn>
Order allow,deny
Deny from all
</DirectoryMatch>
который будет генерировать 403 Forbidden (что лучше с точки зрения соответствия HTTP) или, если вы хотите использовать безопасность по маршруту неизвестности, используйте AliasMatch
AliasMatch \.svn /non-existant-page
Если у вас нет доступа к основным файлам конфигурации, вы остаетесь с надеждой, что mod_rewrite включен для использования в .htaccess.
Это может быть достигнуто на уровне сервера (рекомендуется), на основе одного виртуального хоста или даже внутри файлов .htaccess, если ваш сервер несколько разрешителен тем, что разрешено в них. Конкретная конфигурация вам нужна:
RewriteEngine On
RewriteRule /\.svn /some-non-existant-404-causing-page
<IfModule autoindex_module>
IndexIgnore .svn
</IfModule>
В первом разделе требуется mod_rewrite. Он заставляет любые запросы с "/.svn" в них (т.е. Любой запрос для каталога или что-либо внутри каталога) внутренне перенаправляться на несуществующую страницу вашего веб-сайта. Это совершенно прозрачно для конечного пользователя и невозможно обнаружить. Это также приводит к ошибке 404, как если бы ваши папки .svn просто исчезли.
Второй раздел является чисто косметическим и скроет папки .svn из модуля autoindex, если он активирован. Это тоже хорошая идея, просто чтобы любопытные души не получали никаких идей.
В той же ситуации я использовал RedirectMatch по двум причинам. Прежде всего, это был единственный метод, который я смог найти, который был разрешен в .htaccess на этом сервере с довольно ограничительной конфигурацией, которую я не мог изменить. Также я считаю, что это чище, потому что он позволяет мне сообщать Apache, что да, там есть файл, но просто притворяйтесь, что он не при обслуживании, поэтому возвращайте 404 (в отличие от 403, который будет раскрывать то, что зрители веб-сайтов не должны знать).
Теперь я рассматриваю следующее как стандартную часть моих файлов .htaccess:
## Completely hide some files and directories. RedirectMatch 404 "(?:.*)/(?:[.#].*)$" RedirectMatch 404 "(?:.*)~$" RedirectMatch 404 "(?:.*)/(?:CVS|RCS|_darcs)(?:/.*)?$"
Я использую следующее, которое возвращает пользователю 404 простое, не обнаруживая, что директория управления версиями фактически существует:
RedirectMatch 404/\. (svn | git) (/| $)
Существует интересный подход, который я использую: проверка (и обновление) выполняется в полностью отдельном каталоге (возможно, на полностью отдельной машине), а затем код копируется туда, где веб-сервер будет читать его с помощью rsync. Правило --exclude в командной строке rsync используется для того, чтобы не копировать любые .svn(и CVS), в то время как исключение -delete исключает их, даже если они были скопированы раньше.
Поскольку как svn update, так и rsync делают дополнительные передачи, это довольно быстро даже для больших сайтов. Он также позволяет вам иметь ваш репозиторий за брандмауэром. Единственное предостережение заключается в том, что вы должны переместить все каталоги с файлами, сгенерированными на сервере (например, файлы/каталог на Drupal), в место вне целевого каталога rsync (rsync будет перезаписывать все при использовании таким образом) и символическую ссылку на него должен быть создан в исходном каталоге rsync. В исходном каталоге rsync также могут быть другие файлы без версии (например, файлы конфигурации, специфичные для машины).
Полный набор параметров rsync, которые я использую,
rsync -vv --rsh='ssh -l username' -rltzpy --exclude .svn/ --exclude CVS/ --exclude Attic/ --delete-after --delete-excluded --chmod=og-w,Fa-x
Даже тогда для избыточности у меня все еще есть правило конфигурации для предотвращения доступа .svn, скопированное из правила по умолчанию Debian, которое предотвращает доступ .ht * (.htaccess,.htpasswd).
Скрытие каталогов, как говорит Vinko, должно работать. Но, вероятно, было бы проще использовать svn export вместо svn co. Это не должно генерировать каталоги .svn.
Рассмотрите возможность развертывания кода в реальном времени с использованием инструментов управления пакетами операционной системы, а не напрямую с вашего VCS. Это позволит вам обеспечить, чтобы ваши живые пакеты не содержали каталоги метаданных или другие потенциально чувствительные инструменты и данные.