rate limiting

Rate limiting to mechanizm ograniczający liczbę żądań, które jeden klient, konto albo adres IP może wysłać do usługi w określonym oknie czasu. Chroni przed nadużyciami, atakami siłowymi i przeciążeniem serwera. OWASP w zestawieniu API Security Top 10 z 2023 roku wymienia rate limiting wśród podstawowych środków przeciw nieograniczonemu zużyciu zasobów (kategoria API4:2023) ^[1]. Protokół HTTP ma dla tej sytuacji osobny kod odpowiedzi, 429 Too Many Requests ^[2].

Jak działa

Limiter liczy żądania według wybranego klucza i porównuje wynik z progiem. Kluczem bywa adres IP, identyfikator konta, token API albo cała usługa. RFC 6585 celowo nie określa, jak serwer ma rozpoznawać użytkowników i liczyć żądania: limit może obejmować pojedynczy zasób, cały serwer albo grupę serwerów, a użytkownika można wskazać po danych uwierzytelniających lub ciasteczku ^[2].

Gdy próg zostaje przekroczony, serwer odrzuca albo opóźnia kolejne żądania. Odpowiedź 429 oznacza według RFC 6585, że użytkownik wysłał zbyt wiele żądań w danym czasie ^[2]. Powinna zawierać wyjaśnienie i może zawierać nagłówek Retry-After, który mówi, po jakim czasie ponowić próbę ^[2]. Przebieg pokazuje schemat poniżej.

RYS. 1Żądanie przechodzi przez limiter

Popularną realizacją jest moduł limit_req serwera nginx. Ogranicza on tempo przetwarzania żądań dla zdefiniowanego klucza, najczęściej adresu IP, i korzysta z algorytmu „cieknącego wiadra” (leaky bucket) ^[4]. Parametr burst pozwala przyjąć określoną liczbę żądań ponad średnie tempo, a nadmiarowe żądania są domyślnie opóźniane ^[4]. Przykład z dokumentacji nginx ustala średnio jedno żądanie na sekundę z adresu:

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

location /search/ {
    limit_req zone=one burst=5;
}

Odmiany

Limity różnią się kluczem, miejscem egzekwowania i reakcją na przekroczenie. Najważniejsze warianty zestawia tabela.

Reakcja na przekroczenie też bywa różna. Dokumentacja nginx domyślnie zwraca kod 503, a inny kod ustawia dyrektywa limit_req_status ^[4]. CERT Polska wymienia jako reakcje narastające opóźnienia, blokadę czasową, dodatkową weryfikację albo CAPTCHA ^[3].

W WordPressie

Rdzeń WordPressa ma dwa punkty szczególnie narażone na masowe żądania. Dokumentacja wskazuje stronę logowania wp-login.php oraz plik xmlrpc.php, który opisuje jako częsty cel ataków siłowych (brute-force), zwłaszcza przez metodę system.multicall ^[5]. Metoda ta grupuje wiele wywołań w jednym żądaniu, więc limit liczący wyłącznie żądania HTTP jej nie obejmie. OWASP opisuje ten sam problem ogólnie jako brak limitu liczby operacji w pojedynczym żądaniu klienta ^[1]. Więcej o interfejsie w haśle XML-RPC. Kolejnym miejscem są punkty końcowe REST API; zob. niezabezpieczony endpoint REST API.

Dokumentacja WordPressa zauważa, że nawet nieudany atak siłowy może przeciążyć stronę samą liczbą żądań ^[5]. Dlatego ważne jest, na której warstwie działa limit. Wtyczki ograniczające logowanie działają wewnątrz PHP i przy silnym ataku same zużywają zasoby ^[5]. Limity na poziomie serwera, na przykład limit_req_zone w nginx, przykładowo z tempem rate=10r/m dla logowania, odcinają ruch wcześniej ^[5]. Najwcześniej działa zarządzany WAF na brzegu sieci: ruch jest blokowany, zanim dotrze do serwera ^[5]. Dokumentacja wymienia też fail2ban, który po analizie logów czasowo blokuje nadużywające adresy ^[5].

Na poziomie aplikacji rate limiting ma zwykle postać limitu prób logowania, który liczy nieudane próby dla konta i adresu.

Zagrożenia i skutki

Brak limitu jest znaną słabością. MITRE opisuje ją jako CWE-307: produkt nie stosuje wystarczających środków przeciw wielu nieudanym próbom uwierzytelnienia w krótkim czasie ^[6]. Jako przykład podaje CVE-2019-0039, w którym REST API miało wysokie limity połączeń, co umożliwiało zgadywanie haseł ^[6].

Bez ograniczeń łatwiejsze są:

• credential stuffing i password spraying, czyli masowe próby logowania wyciekłymi lub popularnymi hasłami;
• enumeracja użytkowników przez wielokrotne odpytywanie formularzy i API;
• scraping treści i danych przez złośliwe boty;
• HTTP flood i inne formy przeciążenia warstwy aplikacji.

OWASP zwraca uwagę, że nadmierne zużycie zasobów prowadzi do odmowy usługi, ale też do wzrostu kosztów infrastruktury, na przykład mocy obliczeniowej i przestrzeni w chmurze ^[1]. Wśród limitów, których brak czyni API podatnym, wymienia między innymi czas wykonania, pamięć, rozmiar przesyłanych plików, liczbę operacji w jednym żądaniu i limit wydatków u zewnętrznych dostawców usług ^[1].

Jak się bronić

CERT Polska zaleca liczyć próby uwierzytelnienia jednocześnie dla konta i dla źródła żądania oraz nie opierać limitów wyłącznie na adresie IP ^[3]. Limity trzeba egzekwować po stronie serwera, spójnie we wszystkich instancjach aplikacji ^[3]. Powinny obejmować wszystkie etapy uwierzytelniania, także resetowanie hasła i weryfikację kodów MFA ^[3].

• Ustal progi według potrzeb biznesowych, osobno dla kosztownych operacji ^[1].
• Odrzucaj nadmiar kodem 429 z nagłówkiem Retry-After, żeby uczciwi klienci wiedzieli, kiedy wrócić ^[2].
• Umieszczaj limit jak najbliżej brzegu: w CDN lub reverse proxy, a dopiero potem w aplikacji ^[5].
• Łącz rate limiting z innymi mechanizmami; sam nie zatrzyma rozproszonego ataku DDoS z tysięcy adresów.

MITRE jako środki przeciw CWE-307 wymienia rozłączanie po określonej liczbie nieudanych prób, przerwy czasowe, blokadę atakowanego konta i wymaganie od klienta zadania obliczeniowego ^[6].