brak ograniczenia liczby żądań

Brak ograniczenia liczby żądań to luka bezpieczeństwa dopuszczająca nieograniczoną liczbę zapytań kierowanych do systemu.

Na czym polega brak ograniczenia liczby żądań

Brak ograniczenia liczby żądań, określany także jako brak mechanizmu rate limiting, oznacza, że aplikacja lub usługa nie kontroluje dostatecznie częstości zapytań wysyłanych przez klienta. System może przyjmować kolejne żądania HTTP, wywołania interfejsu API, próby logowania albo zapytania do formularza bez sprawdzania, czy ich liczba w określonym czasie nie przekracza ustalonego poziomu. Sam fakt, że pojedyncze żądanie jest poprawne składniowo i przechodzi uwierzytelnienie, nie oznacza jeszcze, że nie powinno być objęte takim ograniczeniem.

W praktyce problem nie musi oznaczać całkowitego braku jakiejkolwiek kontroli. Luka może powstać również wtedy, gdy limit jest ustawiony zbyt wysoko, dotyczy wyłącznie adresu IP, nie obejmuje wszystkich punktów końcowych albo jest resetowany przy każdej zmianie połączenia. Znaczenie ma także miejsce zastosowania mechanizmu. Ograniczenie na stronie logowania powinno chronić przed wieloma próbami uwierzytelnienia, a ograniczenie przy kosztownym zapytaniu wyszukiwawczym powinno zmniejszać ryzyko przeciążenia procesora, pamięci, bazy danych lub łącza.

Skutki dla dostępności i uwierzytelniania

Nieograniczona liczba żądań ułatwia automatyzację powtarzalnych operacji. Przy logowaniu może to umożliwić atak brute force, czyli systematyczne sprawdzanie wielu haseł dla jednego konta. Jeżeli aplikacja nie stosuje dodatkowych zabezpieczeń, takich jak opóźnienie, czasowa blokada, dodatkowy etap uwierzytelniania lub limit prób, osoba atakująca może wykonywać kolejne próby znacznie szybciej niż użytkownik korzystający z interfejsu ręcznie. Brak ograniczenia nie ujawnia sam w sobie prawidłowego hasła, ale zwiększa tempo testowania zgadywanych danych i automatycznych kombinacji.

Ten sam błąd może zostać wykorzystany przeciwko dostępności usługi. Duża liczba żądań zużywa zasoby potrzebne do obsługi zwykłych użytkowników: czas procesora, pamięć, liczbę połączeń, pulę wątków, miejsce na logi oraz przepustowość sieci. Szczególnie obciążające są operacje wykonujące sortowanie, filtrowanie, generowanie raportów, wysyłanie wiadomości, przeliczanie danych albo odwołania do zewnętrznych usług. W skrajnym przypadku aplikacja zaczyna odpowiadać z dużym opóźnieniem, zwraca błędy przeciążenia lub przestaje przyjmować nowe połączenia. Warto odróżnić taki problem aplikacyjny od rozproszonego ataku DDoS, ponieważ lokalny limit żądań jest tylko jednym z elementów większej ochrony infrastruktury.

Jak rozpoznać problem w działaniu aplikacji

Podczas analizy można porównać zachowanie usługi przy pojedynczym żądaniu i przy serii identycznych żądań wykonywanych w krótkim odstępie. Istotne jest, czy po przekroczeniu rozsądnego progu aplikacja odpowiada kodem HTTP 429 Too Many Requests, zwalnia obsługę, wymaga ponowienia po określonym czasie albo odrzuca kolejne operacje. Sama obecność kodu 429 nie gwarantuje poprawnej ochrony, ponieważ limit może obowiązywać tylko jeden adres IP, działać wyłącznie w jednej instancji aplikacji albo nie obejmować wrażliwego punktu końcowego.

W logach warto szukać powtarzających się wywołań tego samego adresu URL, wielu prób logowania, dużej liczby odpowiedzi 401 lub 403, nagłych wzrostów odpowiedzi 5xx oraz nietypowego zużycia zasobów. Należy jednak uważać na interpretację adresu IP. Użytkownicy za translacją adresów NAT mogą współdzielić jeden publiczny adres, a adres klienta przekazywany w nagłówku HTTP nie powinien być bezkrytycznie uznawany za wiarygodny, jeśli aplikacja nie działa za zaufanym proxy. Weryfikacja powinna obejmować także konto, sesję, klucz API, urządzenie lub inne stabilne identyfikatory, zależnie od sposobu działania konkretnej usługi.

Przy sprawdzaniu nie należy generować agresywnego ruchu wobec systemu produkcyjnego. Bezpieczniejsza jest kontrolowana próba w środowisku testowym albo analiza konfiguracji, kodu i logów. Trzeba ustalić, które żądania są limitowane, jaki jest przedział czasowy, czy licznik działa współbieżnie oraz czy ograniczenie obowiązuje przed wykonaniem kosztownej operacji. Niespójność między kilkoma serwerami może powodować obchodzenie limitu, jeśli każdy z nich prowadzi własny, niezależny licznik.

Projektowanie ograniczeń i diagnostyka urządzenia

Mechanizm rate limiting powinien być dobrany do funkcji aplikacji. Często stosuje się algorytm token bucket, w którym żądania zużywają dostępne tokeny, a ich zapas uzupełnia się w czasie. Pozwala to dopuścić krótkie, kontrolowane serie ruchu bez otwierania drogi do nieograniczonego obciążenia. Innym rozwiązaniem jest stałe albo przesuwne okno czasowe. Limit może być liczony osobno dla adresu IP, konta, klucza API i całej usługi, ponieważ pojedynczy wymiar nie zawsze wystarcza. Dla logowania przydatne jest również narastające opóźnienie po kolejnych nieudanych próbach, natomiast dla operacji kosztownych obliczeniowo potrzebne są limity chroniące sam zasób.

Ograniczenie powinno być połączone z monitoringiem, prawidłowym logowaniem odrzuconych żądań oraz czytelną reakcją klienta. Odpowiedź 429 może zawierać nagłówek Retry-After, który wskazuje, kiedy ponowienie próby ma sens. Nie należy jednak ujawniać szczegółów ułatwiających obchodzenie zabezpieczenia. W przypadku zwykłego laptopa lub komputera PC diagnostyka może obejmować sprawdzenie przeglądarki, aplikacji klienckiej, rozszerzeń, konfiguracji sieciowej i lokalnych logów, ale sam brak limitu jest zazwyczaj problemem po stronie aplikacji lub jej serwera, a nie uszkodzeniem podzespołu.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów, a w przypadku problemu z aplikacją można oddzielić usterkę urządzenia od błędu zewnętrznej usługi. Taka różnica ma znaczenie praktyczne: zawieszanie programu, wysokie użycie procesora lub powolne działanie sieci mogą wynikać z przeciążenia po stronie serwisu internetowego, z lokalnej konfiguracji albo z awarii sprzętowej. Prawidłowa diagnoza powinna ustalić, w którym miejscu przepływu danych powstaje problem, zanim zostanie podjęta decyzja o naprawie lub zmianie konfiguracji.