Path Traversal¶

Path Traversal (znany również jako Directory Traversal) to podatność pozwalająca atakującemu uzyskać dostęp do plików i katalogów znajdujących się poza zamierzonym katalogiem aplikacji. Występuje, gdy aplikacja wykorzystuje dane wejściowe użytkownika do budowania ścieżek do plików bez odpowiedniej walidacji. Najczęściej atakujący wykorzystuje sekwencje: ../ lub ..\, aby „cofać się” po strukturze katalogów systemu. W zależności od uprawnień procesu aplikacji może to prowadzić do ujawnienia plików konfiguracyjnych, danych użytkowników, logów systemowych, kluczy kryptograficznych oraz innych poufnych informacji. Pozyskane dane mogą zostać wykorzystane do dalszej eskalacji ataku, przejęcia kont lub identyfikacji dodatkowych podatności w środowisku.

Skutki udanego ataku¶

Potencjalne skutki ataku Path Traversal:

odczyt poufnych danych, plików użytkowników i konfiguracji systemu,
pozyskanie poświadczeń, tokenów, kluczy API lub kluczy kryptograficznych,
modyfikacja albo usunięcie plików, jeżeli podatna funkcja wykonuje operacje zapisu lub usuwania,
ułatwienie dalszej kompromitacji środowiska,
możliwość uzyskania wykonania kodu w połączeniu z innymi podatnościami.

Sposób działania¶

Aplikacja umożliwia pobieranie plików:

download.php?file=report.pdf

Kod aplikacji:

$file = $_GET['file'];
readfile("/var/www/files/" . $file);

Programista zakłada, że użytkownik będzie pobierał wyłącznie pliki z katalogu /var/www/files/. Atakujący wysyła jednak:

GET /download.php?file=../../../etc/passwd

Serwer interpretuje ścieżkę jako:

/var/www/files/../../../etc/passwd

co po normalizacji daje:

/etc/passwd

W efekcie aplikacja zwraca zawartość pliku systemowego.

Rekomendacje¶

Aby ograniczyć ryzyko występowania podatności należy:

normalizować ścieżki i sprawdzać katalog wynikowy - jeżeli aplikacja musi przyjmować nazwy lub ścieżki plików, powinna odrzucać ścieżki absolutne, sprowadzać ścieżkę wynikową do postaci kanonicznej, a następnie sprawdzać, czy wskazuje ona zasób znajdujący się wewnątrz dozwolonego katalogu bazowego. Kontrola powinna uwzględniać różnice między systemami operacyjnymi, dowiązania symboliczne oraz błędy wynikające z tekstowego porównywania prefiksów. Samo zablokowanie sekwencji ../ lub sprawdzenie początku ścieżki nie stanowi wystarczającego zabezpieczenia,
nie przyjmować nazw ani ścieżek plików bezpośrednio od użytkownika - zamiast rzeczywistej nazwy lub ścieżki użytkownik powinien przekazywać wyłącznie identyfikator zasobu. Aplikacja powinna następnie mapować ten identyfikator po stronie serwera na wcześniej zdefiniowany plik, Zamiast:
```
    GET /download?file=report.pdf
```
Lepiej:
```
    GET /download?id=123
```
wprowadzić listę dozwolonych plików - jeżeli użytkownik musi wskazywać plik, dopuszczaj wyłącznie wcześniej zdefiniowane wartości. W takim modelu użytkownik nigdy nie ma wpływu na rzeczywistą ścieżkę systemową,
```
    ALLOWED_FILES = {
    "manual": "manual.pdf",
    "terms": "terms.pdf",
    "policy": "privacy.pdf"
    }
```
poprawnie obsługiwać kodowanie znaków - aplikacja powinna zdefiniować jeden kanoniczny etap dekodowania danych wejściowych, a następnie wykonywać walidację na znormalizowanej wartości. Nie należy wielokrotnie dekodować danych „w pętli”, ponieważ może to prowadzić do nieprzewidywalnego przetwarzania wejścia. Warto również odrzucać wartości zawierające wielokrotnie zakodowane lub niekanoniczne reprezentacje znaków, jeżeli nie są one wymagane przez funkcjonalność aplikacji,
ograniczyć uprawnienia procesu aplikacji - nawet jeśli wystąpi podatność, skutki można ograniczyć poprzez odpowiednią konfigurację systemu. Proces aplikacji powinien mieć dostęp wyłącznie do plików niezbędnych do działania, a nie powinien mieć dostępu do np. /etc/shadow, katalogu /root, C:\Windows\System32 ani plików zawierających hasła, klucze prywatne czy konfiguracje innych usług,
stosować izolacje środowiska. Dodatkową warstwę ochrony zapewniają np.: kontenery Docker, jail, sandboxing czy separacja usług. Dzięki temu nawet skuteczny Path Traversal nie pozwoli opuścić wydzielonego środowiska aplikacji.
monitorować próby ataków - w logach warto wykrywać charakterystyczne wzorce:
```
    ../
    ..\
    %2e%2e
    /etc/passwd
```