Katalog .git w web aplikacji

Series: publications March 09, 2018

Jednym z często popełnianych błędów, który stwarza ogromny problem i narusza polityki bezpieczeństwa aplikacji jest udostępnianie katalogu .git w zasobach publicznych.

Jako administratorzy powinniśmy mieć pełną kontrolę nad udostępnianymi zasobami z serwisów produkcyjnych, które obsługujemy - i nie chodzi tutaj tylko o ruch wychodzący z serwerów backend’owych. Bardzo często developerzy przemycą zasoby, które będą dostępne na świat lub po prostu zapomną dodać odpowiednich reguł filtrujących po swojej stronie.

Spis treści

Wprowadzenie

Często niestety się zdarza, że takim zasobem jest katalog .git, którego pobranie przez osobę nieuprawnioną pozwala na uzyskanie praktycznie wszystkich informacji o danym projekcie.

Zalecanym sposobem projektowania aplikacji jest wydzielenie osobnego katalogu (np. katalog /public), w którym znajduje się główny punkt “wejścia” dla wszystkich wprowadzanych do aplikacji żądań oraz wydzielenie go poziom niżej z głównego drzewa katalogów projektu.

Większość framework’ów tj. Laravel jest skonfigurowana właśnie w ten sposób.

Przykład:

|-- The Root Directory
  |--  The app Directory
  |--  The bootstrap Directory
  |--  The config Directory
  |--  The database Directory
  |--  The public Directory
  |--  The resources Directory
  |--  The routes Directory
  |--  The storage Directory
  |--  The tests Directory
  |--  The vendor Directory

Swego czasu idealnym przykładem aplikacji (nie wiem czy do tej pory tak jest), z poziomu której wszystko działało z jednego miejsca był Wordpress - łatwo w takiej sytuacji o pomyłkę, która może mieć katastrofalne skutki.

Do dalszej analizy oraz szerszego spojrzenia na ten temat polecam świetny artykuł: Hidden directories and files as a source of sensitive information about web application.

Konfiguracja

Podczas budowania filtra dla ciągu .git pamiętajmy o odpowiednim wyrażeniu regularnym.

Podając dokładnie ciąg .git w specyficznym warunku np. varnish’a, filtr będzie chwytał wszystko co zawiera w nazwie ten ciąg znaków, np. digital. Po ustawieniu reguły filtrującej należy przetestować ją na kilka sposobów.

Do testowania wyrażeń regularnych polecam poniższe narzędzia:

W tym artykule zaprezentuję przykład konfiguracji dla dwóch znanych serwerów http/https: Varnish oraz Nginx.

Varnish

Zabezpieczeniem, które należy wprowadzić w konfiguracji varnish’a i to niezależnie od tego czym obsługujemy ruch https (bądź go w ogóle nie obsługujemy) jest przechwytywanie wystąpienia ciągu znaków .git w podanym zapytaniu.

Wygląda to tak:

sub vcl_recv {

  if (req.url ~ "\.git") {
    return (synth(403, "Not allowed"));
  }

}

Nginx

W przypadku nginx’a przechwytywany ciąg znaków jest oczywiście ten sam jednak z drugiej strony sytuacja wygląda trochę inaczej ponieważ podane restrykcje będą musiały być zastosowane w odpowiednim kontekście, np. dla każdej konfiguracji zawierającej dyrektywę (lub dyrektywy) listen lub inny sposób z dyrektywą location (jednak będzie trzeba ją dodać dla każdej domeny).

Wygląda to mniej więcej tak:

listen 192.168.252.2:443 ssl;

# Headers, SSL configuration and other.

if ($request_uri ~ "/\.git") {
  return 403;
}

W przypadku dyrektywy location konfiguracja może wyglądać tak:

location ~ "/\.git" {
  deny all;
}

Także dobrym pomysłem jest dodanie do listy wykluczeń ścieżek tj. .svn czy .htaccess:

location ~* ^.*(\.(?:git|svn|htaccess))$ {

  return 403;

}

built with Jekyll and trimstray blog — read the fine print