Co to jest Path Traversal
Autor: Redakcja Domeny.ForSale Opublikowano
W skrócie: Path Traversal to luka bezpieczeństwa, przez którą aplikacja pozwala sięgnąć do plików poza katalogiem przeznaczonym do obsługi danego żądania. Najczęściej kojarzy się z odczytem cudzych plików, ale przy funkcjach zapisu lub usuwania może umożliwić także ich zmianę albo skasowanie. Problem powstaje wtedy, gdy aplikacja traktuje dane od użytkownika jako część ścieżki do pliku i nie sprawdza skutecznie, dokąd ta ścieżka prowadzi.
Na czym polega wyjście poza katalog
Ścieżka to adres pliku w systemie plików, na przykład /srv/aplikacja/dokumenty/instrukcja.pdf. Aplikacja udostępniająca dokumenty powinna pozwalać pobierać wyłącznie pliki z wyznaczonego miejsca, a nie dowolne pliki dostępne na serwerze.
Path Traversal, nazywany też directory traversal lub dot-dot-slash, polega na przekroczeniu tej granicy. Nazwa dot-dot-slash odnosi się do zapisu ../: dwie kropki oznaczają katalog nadrzędny, a ukośnik oddziela elementy ścieżki. Odpowiednio użyta sekwencja może więc skierować operację poza dozwolony folder.
Można porównać to do okienka wydawania dokumentów. Klient powinien podać numer dokumentu, a pracownik wydać go z właściwej szafy. Błąd pojawia się wtedy, gdy pracownik zamiast numeru przyjmuje instrukcję: „wyjdź z tej szafy, przejdź do sąsiedniego pokoju i weź wskazany plik”.
Przykład: pobieranie dokumentu po nazwie
Załóżmy, że aplikacja przechowuje publiczne dokumenty w katalogu /srv/aplikacja/dokumenty/. Użytkownik wybiera plik, a przeglądarka wysyła żądanie:
/pobierz?plik=instrukcja.pdf
Jeżeli program bez sprawdzenia dokleja wartość parametru plik do katalogu dokumentów, otrzyma ścieżkę /srv/aplikacja/dokumenty/instrukcja.pdf. Dla zwykłej nazwy wygląda to poprawnie. Problem ujawnia się po podaniu wartości zawierającej przejście do katalogu nadrzędnego:
/pobierz?plik=../konfiguracja.env
Złożona ścieżka /srv/aplikacja/dokumenty/../konfiguracja.env wskazuje na /srv/aplikacja/konfiguracja.env, czyli plik spoza katalogu dokumentów. Jeśli aplikacja może go odczytać i zwraca jego zawartość, dochodzi do ujawnienia danych.
To przykład mechanizmu, nie gwarancja skutecznego ataku. Plik musi istnieć, proces aplikacji musi mieć do niego dostęp, a sposób obsługi żądania musi pozwalać wykorzystać podaną ścieżkę. Takie zachowanie należy sprawdzać wyłącznie we własnym środowisku lub w ramach wyraźnej zgody na testy.
Jakie szkody może spowodować Path Traversal
Skutek zależy przede wszystkim od tego, jaką operację wykonuje podatna funkcja i jakie uprawnienia ma aplikacja w systemie operacyjnym.
- Odczyt plików: funkcja pobierania może ujawnić konfigurację, dane użytkowników, kopie zapasowe lub dane dostępowe.
- Zapis i nadpisywanie: podatny mechanizm zapisu może umieścić plik poza docelowym katalogiem albo zmienić istniejący plik.
- Usuwanie: funkcja kasowania plików może usunąć zasoby, których użytkownik nie powinien móc wskazać.
W szczególnych warunkach nadpisanie konfiguracji lub umieszczenie pliku wykonywanego przez serwer może prowadzić do dalszego przejęcia aplikacji. Path Traversal nie oznacza jednak automatycznie możliwości wykonania kodu ani pełnego dostępu do serwera. Ograniczają go między innymi uprawnienia procesu i dostępne funkcje aplikacji.
Luka nie dotyczy wyłącznie adresów widocznych w przeglądarce. Dane wpływające na ścieżkę mogą pochodzić również z formularza, żądania API, nazwy przesyłanego pliku lub wpisu w rozpakowywanym archiwum.
Jak skutecznie ograniczyć ryzyko
Najbezpieczniejszym rozwiązaniem jest unikanie sytuacji, w której użytkownik wskazuje ścieżkę. Zamiast przyjmować nazwę lub położenie pliku, aplikacja może przyjmować identyfikator dokumentu, na przykład 482, i samodzielnie odnajdywać przypisany do niego plik. Musi przy tym sprawdzić, czy dany użytkownik ma prawo go pobrać — identyfikator sam w sobie nie zapewnia ochrony.
Jeżeli przyjmowanie ścieżek jest potrzebne, zabezpieczenie powinno obejmować kilka elementów:
- Ściśle określony zakres wejścia. Jeśli funkcja wymaga tylko nazwy pliku, nie powinna przyjmować całej ścieżki. Dopuszczalne nazwy i rozszerzenia należy ograniczyć do rzeczywistych potrzeb.
- Sprawdzenie końcowego położenia. Po uwzględnieniu reguł systemu plików aplikacja powinna potwierdzić, że cel nadal znajduje się wewnątrz dozwolonego katalogu. Do tego należy używać odpowiednich funkcji obsługi ścieżek, a nie prostego porównania początków tekstu.
- Uwzględnienie dowiązań symbolicznych. Dowiązanie jest odwołaniem do innego miejsca w systemie plików. Plik pozornie znajdujący się w dozwolonym folderze może przez takie odwołanie prowadzić poza niego.
- Minimalne uprawnienia. Proces udostępniający dokumenty nie powinien mieć dostępu do niepotrzebnych danych ani prawa zapisu tam, gdzie wystarczy odczyt.
Samo usuwanie ciągu ../ nie jest wystarczającą ochroną. Różnice w separatorach, kodowaniu i kolejności przetwarzania danych mogą sprawić, że filtr oraz system plików inaczej zinterpretują tę samą wartość. Kontrola musi odpowiadać temu, jak aplikacja faktycznie otwiera plik.
Od czego zacząć sprawdzanie aplikacji
Przejrzyj funkcje pobierania, przesyłania, usuwania i rozpakowywania plików. Dla każdej ustal, czy użytkownik wpływa na ścieżkę, jaki katalog jest dozwolony oraz czy program sprawdza końcowy cel operacji. Testy powinny obejmować zarówno próby wyjścia poza katalog, jak i zwykłe, prawidłowe żądania.
Jeśli podejrzewasz wykorzystanie luki, samo poprawienie kodu może nie wystarczyć. Trzeba ocenić, jakie pliki były dostępne, sprawdzić logi i — jeżeli mogły wyciec dane dostępowe — wymienić odpowiednie hasła lub klucze. Pierwszy praktyczny krok to wskazanie konkretnego miejsca, w którym dane użytkownika stają się ścieżką do pliku.
Zobacz też: Co to jest Apache?
Przeczytaj także
