Reagowanie na automatyczne próby logowania (credential stuffing), enumerację kont i nadużycia API (scraping, przekroczenie limitów, kosztowne endpointy) — bez blokowania legalnych użytkowników. Poziom 1 (cyber klasyczny). Priorytet typowy P1, podbijany do P0 przy potwierdzonym przejęciu konta.
Skuteczna detekcja wymaga korelacji konta, IP, ASN, urządzenia, tempa żądań i wyniku logowania jednocześnie. To najczęstszy wektor testowany w ćwiczeniach appsec/API-security dla panelu logowania, warstwy OAuth/token oraz punktów resetu hasła.
Boty testują wykradzione pary login/hasło (leak z innych serwisów) na masową skalę, licząc na powtórne użycie haseł. Nadużycie API rozszerza to na enumerację ID, scraping paginacji i wywołania kosztownych endpointów. Skutki:
/users/1, /users/2…) → potencjalny wyciek osobowy,Bez poniższych pól nie da się korelować ataku po IP, koncie, urządzeniu i endpointach:
timestamp, endpoint, method, status_code, request_id, session_id, latency.
user_id jeśli znany, login/email/phone_hash (zahaszowane, nie w plaintext).
ip, asn, country, user_agent, device_id / fingerprint.
success / fail / mfa_required / locked / rate_limited + wynik captcha/challenge.
Trigger, jeśli w oknie 5–15 min wystąpi: wiele nieudanych logowań z jednego IP/ASN, wiele różnych kont z jednego IP, to samo konto atakowane z wielu IP, wysoki stosunek fail/success, rotacja User-Agent przy podobnym wzorcu żądań, wzrost 401/403 na /login, /token, /oauth/token.
IP: >50 failed logins / 10 min Account: >10 failed logins / 10 min ASN: >500 failed logins / 10 min Endpoint /login: fail_rate > baseline * 3
Progi startowe — muszą być kalibrowane do ruchu produkcyjnego odbiorcy, nie kopiowane bez adaptacji.
/users/1, /users/2, /users/3…,404/403 z jednego klienta,| Endpoint | Limit | Uwaga |
|---|---|---|
/login | IP 20/min · konto 5/min · subnet 200/min | + kara po nieudanym logowaniu (failed_login_penalty) |
/oauth/token | client_id 60/min · IP 30/min | — |
/password-reset | konto 3/godz · IP 10/godz | zapobiega enumeracji przez reset |
Rate limit per IP, konto, token, fingerprint, ASN/kraj (przy ataku), endpoint — z dynamicznymi limitami zależnymi od poziomu ryzyka. Blokada znanych złych ASN/proxy/VPN tylko jako jedna z reguł ryzyka, nigdy jedyny sygnał. WAF/bot management, jeśli dostępny.
Warunki: masowy atak na logowanie, potwierdzone przejęcia kont, wpływ na dostępność API.
Przykładowy szkielet zapytań do korelacji ataku (dostosuj do własnego schematu logów):
-- credential stuffing: IP z anomalnym wolumenem fail SELECT ip, count(*) fails, count(distinct login_hash) accounts FROM auth_logs WHERE ts > now() - interval '15 minutes' AND result = 'fail' GROUP BY ip HAVING count(*) > 50 ORDER BY fails DESC;
-- konta z ryzykiem przejecia (fail wysoki + co najmniej 1 success)
SELECT login_hash,
count(*) FILTER (WHERE result='fail') fails,
count(*) FILTER (WHERE result='success') successes,
count(distinct ip) ips
FROM auth_logs
WHERE ts > now() - interval '24 hours'
GROUP BY login_hash
HAVING count(*) FILTER (WHERE result='fail') > 5
AND count(*) FILTER (WHERE result='success') > 0;
-- API abuse: wolumen po kluczu API i endpoincie SELECT api_key_hash, endpoint, count(*) requests, count(distinct ip) ips FROM api_logs WHERE ts > now() - interval '1 hour' GROUP BY api_key_hash, endpoint ORDER BY requests DESC;
Neutralny komunikat dla nieudanego logowania: Nie udało się zalogować. Sprawdź dane lub spróbuj później. Dla kont podejrzanych: Ze względów bezpieczeństwa wymagamy dodatkowej weryfikacji.
Nigdy nie ujawniaj: czy konto istnieje, czy hasło było poprawne, czy konto jest zablokowane właśnie z powodu ataku — każda z tych informacji ułatwia atakującemu enumerację.
login_fail_rate, login_success_after_fail, account_takeover_confirmed.
failed_logins_per_ip, failed_logins_per_account, distinct_accounts_per_ip.
rate_limited_requests, captcha_solve_rate, mfa_challenge_rate.
false positive rate (blokada legalnych użytkowników), latency endpointów auth.
| Priorytet | Zakres |
|---|---|
| P0 | Rate limit per IP + konto na /login · neutralne błędy logowania · logowanie pól auth/security · alert na wzrost 401 · MFA dla adminów · unieważnianie sesji po zmianie hasła. |
| P1 | Risk scoring · step-up MFA · CAPTCHA adaptacyjna · detekcja ASN/proxy · dashboard SOC. |
| P2 | Bot management · device fingerprinting · modele anomalii · playbooki SOAR (ROADMAP — automatyzacja poza szkieletem opisanym tu). |
| Warunek | Flaga | Obowiązek |
|---|---|---|
| Enumeracja/scraping ujawniła dane osobowe | GDPR_PERSONAL_DATA | Ocena naruszenia — patrz Playbook E |
| Potwierdzone przejęcie kont z danymi | GDPR_BREACH | RODO art. 33 — zgłoszenie do PUODO w 72h; art. 34 przy wysokim ryzyku |
| Podmiot to usługa kluczowa/ważna | NIS2_RELEVANT | Wczesne ostrzeżenie CSIRT 24h, zgłoszenie 72h, raport końcowy |
Formularz Intake uruchamiający ten playbook. → Incident Intake
Reguły kierujące zdarzenie do Playbooka M. → Classification Engine
Sprzężenie gdy enumeracja/przejęcie kont → dane osobowe. → Playbook E
Gdy nadużycie API wykorzystuje lukę w logice biznesowej. → Playbook D
>50 failed logins / 10 min) to punkt startowy do kalibracji na ruchu odbiorcy, nie wartości uniwersalne. Zapytania SQL to szkielet ilustrujący logikę korelacji, nie gotowy produkt do wdrożenia bez adaptacji do własnego schematu logów. Ramki RODO/NIS2 opierają się na treści regulacji (norma), nie na konkretnym incydencie.