brak limitów eksportów

Brak limitów eksportów to luka bezpieczeństwa umożliwiająca nieograniczone pobieranie danych z systemu.

Na czym polega brak limitów eksportów

Brak limitów eksportów oznacza, że aplikacja pozwala użytkownikowi lub automatycznemu klientowi wielokrotnie pobierać dane bez określenia maksymalnej liczby rekordów, plików, raportów albo żądań w danym przedziale czasu. Sam eksport może być funkcją prawidłową, lecz problem powstaje wtedy, gdy system nie kontroluje jego skali. Ograniczenie powinno uwzględniać co najmniej liczbę wyeksportowanych elementów, rozmiar generowanego pliku, częstotliwość żądań oraz uprawnienia konta wykonującego operację.

Nieograniczony eksport nie musi oznaczać błędu w algorytmie szyfrowania ani awarii sprzętu. Jest to przede wszystkim błąd w kontroli dostępu, walidacji parametrów i zarządzaniu zasobami aplikacji. Jeżeli endpoint przyjmuje parametr określający zakres danych i nie sprawdza jego maksymalnej wartości, klient może próbować pobrać cały dostępny zbiór zamiast pojedynczej strony wyników. Podobnie niebezpieczne jest pozostawienie eksportu działającego w tle bez limitu czasu, liczby równoległych zadań lub wielkości rezultatu.

Skutki niekontrolowanego pobierania danych

Najbardziej bezpośrednim skutkiem jest zwiększenie zakresu danych dostępnych dla konta, które uzyskało możliwość eksportu. Jeżeli autoryzacja sprawdza tylko fakt zalogowania, a nie zakres uprawnień do konkretnych rekordów, użytkownik może otrzymać dane należące do innych jednostek, projektów lub działów. W takim przypadku brak limitu eksportu łączy się z błędem kontroli dostępu. Sam limit liczby rekordów nie naprawia niewłaściwej autoryzacji, ale ogranicza rozmiar pojedynczego wycieku i utrudnia masowe pobranie.

Duże eksporty obciążają procesor, pamięć operacyjną, magazyn danych oraz połączenia sieciowe. Aplikacja może najpierw wykonać kosztowne zapytanie, następnie zbudować cały plik w pamięci, skompresować go i przesłać przez HTTP. Przy wielu równoległych żądaniach prowadzi to do wzrostu czasu odpowiedzi, błędów przekroczenia limitu czasu, zajęcia puli połączeń do bazy danych oraz odrzucania poprawnych żądań innych użytkowników. W skrajnym przypadku eksport staje się prostym mechanizmem wyczerpywania zasobów, podobnym do ataku odmowy usługi na poziomie aplikacji.

Ryzyko zwiększa brak rejestrowania operacji. Jeżeli system nie zapisuje identyfikatora konta, zakresu eksportu, liczby rekordów, rozmiaru pliku, adresu źródłowego i czasu wykonania, późniejsze ustalenie skali pobierania jest utrudnione. Logowanie nie zastępuje zabezpieczenia, ale pozwala wykryć nietypowe wzorce, takie jak setki żądań w krótkim czasie, eksport całej historii lub powtarzanie tego samego zakresu danych.

Kontrole ograniczające zakres eksportu

Podstawową kontrolą jest limit liczby rekordów zwracanych w jednym żądaniu oraz wymuszenie stronicowania po stronie serwera. Parametry przesyłane przez klienta nie powinny samodzielnie decydować o maksymalnym rozmiarze odpowiedzi. Serwer powinien narzucać własną wartość graniczną, odrzucać wartości ujemne i nadmiernie duże oraz kontrolować sortowanie i filtrowanie. Przy eksporcie plikowym można dodatkowo ograniczyć maksymalny rozmiar rezultatu i liczbę elementów przypadających na jedno zadanie.

Drugą warstwą jest limit częstotliwości, czyli rate limiting. Może być liczony dla konta, klucza API, adresu sieciowego lub kombinacji tych identyfikatorów. W odpowiedzi HTTP serwer może zwracać kod 429 Too Many Requests oraz nagłówek Retry-After, gdy klient przekroczy dozwoloną częstotliwość. Limity powinny obejmować także zadania asynchroniczne, ponieważ przeniesienie generowania pliku do kolejki nie usuwa problemu nieograniczonego żądania.

Ważne jest rozdzielenie uprawnień do uruchomienia eksportu od uprawnień do odczytu danych. Przed utworzeniem pliku aplikacja powinna ponownie sprawdzić zakres dostępu dla każdego pobieranego obiektu lub zastosować zapytanie ograniczone do dozwolonego zbioru. Należy również ustalić czas wygaśnięcia odnośnika do gotowego pliku, unieważniać go po pobraniu i usuwać pliki tymczasowe po zakończeniu retencji. Weryfikacja powinna obejmować testy wartości granicznych, równoległe żądania, przerwane pobieranie, zmianę uprawnień w trakcie zadania oraz próbę odgadnięcia adresu cudzego eksportu.

Sprawdzenie komputera po incydencie eksportowym

Na komputerze użytkownika warto sprawdzić, czy podczas eksportu nie doszło do zapełnienia dysku, nadmiernego użycia pamięci lub pozostawienia dużych plików tymczasowych. W systemie Windows można przejrzeć katalog Pobrane, foldery tymczasowe oraz historię pobierania przeglądarki. Należy zwrócić uwagę na pliki o nietypowym rozmiarze, wielokrotnie zapisane kopie tego samego raportu i komunikaty o braku wolnego miejsca. Sama obecność dużego pliku nie dowodzi wycieku danych, dlatego trzeba porównać jego pochodzenie z historią operacji na koncie i logami aplikacji.

Jeżeli eksport został wykonany z użyciem tokenu API, sesji przeglądarki lub zapisanych poświadczeń, po incydencie należy unieważnić aktywne sesje i wygenerować nowe klucze zgodnie z procedurą danego systemu. Nie powinno się przesyłać pobranych plików pocztą ani przechowywać ich bez kontroli dostępu. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego może sprawdzić stan techniczny urządzenia, miejsce na dysku oraz podstawowe ślady lokalnego problemu po masowym pobieraniu danych.

Ostateczna naprawa wymaga jednak zmiany po stronie aplikacji: ustalenia limitów, poprawy autoryzacji, kontroli zadań eksportowych i monitorowania nietypowego ruchu. Aktualizacja systemu operacyjnego lub wymiana dysku nie usuwa luki w mechanizmie eksportu. Działania sprzętowe mogą przywrócić sprawność komputera, natomiast ograniczenie pobierania musi zostać wdrożone w kodzie aplikacji, konfiguracji bramy API albo usłudze obsługującej dane.