Co to jest atak LFI?

Atak LFI, czyli Local File Inclusion, to luka w aplikacji internetowej, która pozwala osobie atakującej wymusić załadowanie lokalnego pliku znajdującego się na serwerze. Najczęściej dzieje się tak wtedy, gdy aplikacja pobiera nazwę pliku z parametru w adresie URL, formularza lub ciasteczka i nie sprawdza jej wystarczająco dokładnie.

W praktyce LFI może prowadzić do odczytu plików konfiguracyjnych, logów, fragmentów kodu, danych dostępowych albo innych informacji, które nie powinny być widoczne dla użytkownika strony. W niektórych scenariuszach atak może być etapem prowadzącym do przejęcia aplikacji, zwłaszcza gdy atakujący połączy go z błędami w logowaniu danych, uploadzie plików albo konfiguracji serwera.

Najważniejsze pytanie brzmi: czy użytkownik może wpływać na ścieżkę pliku? Jeśli tak, aplikacja powinna traktować taki parametr jako potencjalnie niebezpieczny i dopuścić wyłącznie znane, z góry określone wartości.

Jak działa Local File Inclusion?

Atak LFI wykorzystuje sytuację, w której aplikacja tworzy ścieżkę do pliku na podstawie danych przesłanych przez użytkownika. Atakujący próbuje wtedy użyć specjalnych sekwencji znaków, na przykład ../, aby wyjść poza katalog, który aplikacja miała obsługiwać.

Takie zachowanie jest blisko powiązane z techniką znaną jako path traversal. Jej celem jest przejście do katalogów nadrzędnych i odczyt plików, które powinny pozostać niedostępne z poziomu przeglądarki. W systemach linuksowych często podaje się przykładowo pliki systemowe, a w aplikacjach webowych szczególnie groźne są pliki konfiguracyjne, logi, klucze, dane połączenia z bazą lub fragmenty kodu.

Przykładowy podatny schemat może wyglądać tak:

example.pl/index.php?page=kontakt

Jeśli aplikacja nie sprawdza wartości parametru page, atakujący może próbować zmienić go na ścieżkę prowadzącą poza oczekiwany katalog. Nie chodzi o to, że sama obecność parametru jest błędem. Błędem jest zaufanie do wartości pochodzącej od użytkownika.

Warto zapamiętać: LFI nie musi od razu oznaczać pełnego przejęcia serwera. Już sam odczyt pliku konfiguracyjnego może dać atakującemu informacje potrzebne do kolejnego etapu ataku.

Co może ujawnić atak LFI?

Skutki LFI zależą od konfiguracji aplikacji, uprawnień procesu serwera WWW i tego, jakie pliki są dostępne lokalnie. Najczęstsze ryzyko to ujawnienie danych, które nie powinny trafić do użytkownika końcowego.

• Pliki konfiguracyjne z danymi połączenia z bazą, kluczami API lub ustawieniami aplikacji.
• Logi serwera i aplikacji, które mogą zawierać ścieżki, błędy, adresy IP, nagłówki lub fragmenty zapytań.
• Kod źródłowy, który ułatwia znalezienie kolejnych luk.
• Pliki systemowe, jeśli uprawnienia i konfiguracja serwera na to pozwalają.
• Dane sesyjne lub tymczasowe, gdy aplikacja przechowuje je w przewidywalnych lokalizacjach.

LFI, RFI i path traversal. Czym się różnią?

Te pojęcia są często używane obok siebie, dlatego łatwo je pomylić. Warto rozdzielić je już na poziomie definicji.

• LFI dotyczy włączenia lub odczytu pliku lokalnego, czyli znajdującego się na tym samym serwerze lub w jego dostępnym systemie plików.
• RFI, czyli Remote File Inclusion, polega na próbie dołączenia pliku z zewnętrznej lokalizacji, na przykład z innego serwera.
• Path traversal to technika manipulowania ścieżką, zwykle przez sekwencje typu ../, aby wyjść poza dozwolony katalog.

W praktyce LFI często korzysta z path traversal, ale nie każde path traversal jest klasycznym LFI. Atak może polegać na odczycie pliku, pobraniu zasobu, ujawnieniu ścieżki, a w bardziej złożonych przypadkach także na przygotowaniu warunków do wykonania kodu.

Jak ograniczyć ryzyko ataku LFI?

Wybór odpowiedniego hostingu WWW z dodatkowymi zabezpieczeniami może pomóc w ochronie przed tego typu atakami, ale nie zastąpi poprawnej walidacji i bezpiecznej logiki ładowania plików. Najskuteczniejsza ochrona przed LFI zaczyna się w kodzie aplikacji.

Używaj listy dozwolonych wartości

Zamiast przyjmować nazwę pliku od użytkownika, aplikacja powinna mapować krótką, znaną wartość na konkretny plik. Przykład: parametr page=kontakt może oznaczać plik przypisany w kodzie, ale użytkownik nie powinien decydować o pełnej ścieżce do pliku.

Nie opieraj się na samym filtrowaniu znaków

Usuwanie podejrzanych fragmentów, takich jak ../, bywa niewystarczające. Atakujący może używać kodowania znaków, podwójnego kodowania, separatorów charakterystycznych dla różnych systemów operacyjnych albo innych wariantów ścieżek. Bezpieczniejszym podejściem jest dopuszczanie tylko znanych wartości i odrzucanie całej reszty.

Ogranicz uprawnienia i dostęp do plików

Proces aplikacji nie powinien mieć dostępu do wszystkiego na serwerze. Pliki konfiguracyjne, kopie zapasowe, archiwa i katalogi robocze powinny być przechowywane oraz zabezpieczone tak, aby nie dało się ich pobrać przez przeglądarkę. Przy projektach wymagających większej kontroli nad środowiskiem warto rozważyć serwer VPS, ale tylko wtedy, gdy masz plan na jego aktualizacje, konfigurację i administrację.

Stosuj warstwy ochrony

WAF i ModSecurity mogą pomóc wykrywać oraz blokować podejrzane żądania, ale nie są wymówką dla podatnego kodu. Podobnie certyfikat SSL chroni transmisję danych między użytkownikiem a serwerem, ale sam nie naprawia LFI. To ważne rozróżnienie, bo różne mechanizmy odpowiadają za różne warstwy bezpieczeństwa.

Dobra praktyka: potraktuj bezpieczeństwo jak zestaw warstw. Poprawny kod, aktualny CMS, ograniczone uprawnienia, kopie zapasowe, WAF i szyfrowanie połączenia wzajemnie się uzupełniają.

Jak rozpoznać LFI i co zrobić po podejrzeniu ataku?

LFI nie zawsze daje oczywiste objawy dla właściciela strony. Czasem widać tylko nietypowe zapytania w logach, błędy 404, błędy aplikacji albo próby odwołań do podejrzanych ścieżek. Warto zwrócić uwagę na powtarzające się parametry zawierające sekwencje ../, zakodowane znaki specjalne, nazwy plików systemowych lub nietypowe próby odczytu plików konfiguracyjnych.

• Sprawdź logi aplikacji, serwera WWW i WAF, jeśli jest dostępny.
• Zaktualizuj CMS, wtyczki, motywy i moduły, zwłaszcza jeśli luka dotyczy znanego dodatku.
• Wyłącz podatny mechanizm lub ogranicz dostęp do niego do czasu poprawki.
• Zmień dane dostępowe, jeśli mogły znajdować się w ujawnionych plikach.
• Zweryfikuj kopie zapasowe i sprawdź, czy nie doszło do modyfikacji plików.
• Przeprowadź audyt kodu, szczególnie miejsc, w których aplikacja ładuje szablony, tłumaczenia, załączniki lub inne pliki na podstawie parametrów.