W 2023 roku nieautoryzowane webhooki na giełdzie kryptowalut pozwoliły atakującym potwierdzić fałszywe wpłaty, kradnąc ponad 2 miliony dolarów. W 2024 roku podatność w mechanizmie walidacji webhooków (MOVEit) uderzyła w ponad 2000 organizacji naraz. Każda integracja B2B — z ERP, BaseLinkerem, systemem CRM — to w praktyce trwałe, automatyczne połączenie działające poza standardowymi mechanizmami logowania i uwierzytelniania dwuskładnikowego. Jedna słabo zabezpieczona integracja to jedno kliknięcie od realnego incydentu. Poniżej pokazujemy, co konkretnie zabezpieczyć, zanim kolejna integracja trafi na produkcję.
Dlaczego integracje API to inny rodzaj ryzyka niż zwykłe logowanie
Webhook czy token API to tak zwana nieludzka tożsamość (non-human identity) — działa bez przerwy, bez logowania, poza zasięgiem SSO czy uwierzytelniania dwuskładnikowego, które chronią konta pracowników. To sprawia, że pojedyncza integracja, jeśli zostanie skompromitowana, daje atakującemu trwały, niezauważony dostęp — nie jednorazowe włamanie, które ktoś prędzej czy później zauważy przy próbie logowania.
W firmie B2B, gdzie jeden sklep bywa spięty z ERP, systemem księgowym, BaseLinkerem i płatnościami naraz, liczba takich „cichych” połączeń rośnie szybko — a każde jest potencjalnym punktem wejścia.
Weryfikacja podpisu webhooka — podstawa, którą łatwo pominąć
Webhook przyjmujący dane bez weryfikacji, skąd faktycznie pochodzą, jest jednym z najczęściej wykorzystywanych błędów integracji. Standardem branżowym jest weryfikacja podpisu HMAC — nadawca generuje kryptograficzny hash danych przy użyciu wspólnego, tajnego klucza i dołącza go do zapytania. Odbiorca liczy ten sam hash samodzielnie i porównuje. Jeśli się zgadzają, dane są autentyczne i niezmienione.
Kluczowy, często pomijany szczegół: porównanie podpisów musi być wykonane w czasie stałym (constant-time comparison), niezależnym od tego, w którym miejscu porównywane ciągi się różnią. Standardowe porównanie ciągów w wielu językach programowania przerywa się przy pierwszej niezgodności — a różnica w czasie odpowiedzi może zdradzić atakującemu fragment poprawnego podpisu.
Ataki powtórzeniowe — dlaczego sam podpis nie wystarczy
Poprawny podpis nie znaczy, że zapytanie jest świeże. Atakujący, który przechwyci raz poprawnie podpisany webhook, może go wysłać ponownie później, wywołując tę samą akcję (np. potwierdzenie płatności) wielokrotnie. Zabezpieczenie wymaga dwóch elementów naraz:
- Znacznika czasu w nagłówku zapytania, z odrzuceniem wszystkiego starszego niż 5 minut — to rekomendowany przez OWASP maksymalny tolerowany odstęp.
- Kluczy idempotencji — zapisywania identyfikatorów już przetworzonych zdarzeń i odrzucania duplikatów, nawet jeśli trafią w dozwolonym oknie czasowym. To blokuje zarówno złośliwe powtórzenia, jak i przypadkowe duplikaty od dostawców z agresywną polityką ponownych prób.
Autoryzacja na poziomie obiektu — najczęstszy, najbardziej krytyczny błąd API
Aktualna lista OWASP API Security Top 10 wskazuje złamaną autoryzację na poziomie obiektu (BOLA) jako najczęstszy, najbardziej krytyczny problem API. To sytuacja, w której użytkownik z poprawnymi, własnymi danymi uwierzytelniającymi może uzyskać dostęp do danych innego użytkownika, tylko zmieniając identyfikator w zapytaniu — dokładnie ten sam mechanizm, o którym pisaliśmy przy okazji audytu vibe codingu, tu w kontekście integracji, nie całej aplikacji.
Praktyczny test przed wdrożeniem integracji na produkcję: spróbujcie uzyskać dostęp do zasobu innego konta, korzystając z poprawnych danych uwierzytelniających zupełnie innego, testowego konta. Jeśli to się uda — macie problem, który trzeba naprawić przed startem, nie po pierwszym incydencie.
Zarządzanie sekretami — klucze API nie żyją wiecznie
- Przechowujcie dane dostępowe do integracji w dedykowanym menedżerze sekretów, nigdy zapisane bezpośrednio w kodzie ani w plikach konfiguracyjnych trafiających do repozytorium — to ten sam błąd, o którym pisaliśmy przy okazji audytu vibe codingu.
- Rotujcie klucze regularnie, nie tylko wtedy, gdy podejrzewacie wyciek.
- Ograniczajcie uprawnienia każdego klucza do minimum faktycznie potrzebnego — integracja synchronizująca tylko stany magazynowe nie powinna mieć dostępu do danych finansowych czy danych osobowych klientów.
Praktyczny checklist testowy przed wdrożeniem integracji
- Sprawdźcie, czy każdy endpoint wymusza HTTPS i odrzuca zapytania przez zwykłe HTTP.
- Przetestujcie zachowanie po wygaśnięciu tokena — wygasły token musi być odrzucony, nie po cichu zaakceptowany.
- Sprawdźcie, czy dane wejściowe z webhooka są traktowane jako niezaufane i walidowane względem ścisłego schematu, zanim trafią do przetwarzania.
- Jeśli dostawca publikuje zakres adresów IP, z których wysyła zapytania, ograniczcie ruch przychodzący na poziomie sieci wyłącznie do tych adresów.
- Ustawcie limit liczby zapytań na sekundę — legalny dostawca nie wysyła tysiąca zdarzeń naraz do jednego endpointu.
Przykład z praktyki (Klient H, dystrybutor artykułów przemysłowych — przykład poglądowy, dane uśrednione dla tej skali projektu)
Firma miała webhook odbierający potwierdzenia płatności z zewnętrznego dostawcy, wdrożony kilka lat wcześniej, bez weryfikacji podpisu — endpoint akceptował dane, jeśli struktura JSON wyglądała poprawnie, bez sprawdzania, czy faktycznie pochodzi od zaufanego nadawcy. Audyt integracji wykazał, że teoretycznie każdy, kto znał adres endpointu, mógłby wysłać spreparowane potwierdzenie płatności i wywołać oznaczenie zamówienia jako opłaconego.
Wdrożenie weryfikacji podpisu HMAC z porównaniem w czasie stałym, kontroli znacznika czasu i kluczy idempotencji zamknęło tę lukę bez zmiany logiki biznesowej integracji — sama poprawka bezpieczeństwa, bez przebudowy funkcjonalności.
FAQ
Czym jest weryfikacja podpisu HMAC i dlaczego jest standardem dla webhooków? To metoda potwierdzania, że dane w webhooku faktycznie pochodzą od zaufanego nadawcy i nie zostały zmienione — nadawca i odbiorca liczą kryptograficzny hash przy użyciu wspólnego, tajnego klucza i porównują wyniki. Używają jej m.in. Stripe, GitHub i Slack.
Co to jest atak powtórzeniowy (replay attack) na webhook? To ponowne wysłanie przechwyconego, poprawnie podpisanego zapytania w celu wywołania tej samej akcji wielokrotnie. Zabezpiecza przed tym kombinacja kontroli znacznika czasu i kluczy idempotencji.
Czym jest BOLA i dlaczego to najczęstszy problem bezpieczeństwa API? Broken Object Level Authorization to sytuacja, w której użytkownik z poprawnymi danymi uwierzytelniającymi może uzyskać dostęp do zasobów innego użytkownika, zmieniając identyfikator w zapytaniu. To najczęściej wskazywany krytyczny problem na liście OWASP API Security Top 10.
Jak często warto rotować klucze API używane w integracjach B2B? Regularnie, nie tylko w reakcji na podejrzenie wycieku — konkretna częstotliwość zależy od wrażliwości danych, do których dany klucz ma dostęp, ale najlepszą praktyką jest rotacja zaplanowana, nie doraźna.
Czy limit zapytań (rate limiting) jest naprawdę potrzebny na endpointach webhookowych? Tak. Legalny dostawca danych nie wysyła nagłego, masowego ruchu do jednego endpointu — nietypowy skok liczby zapytań jest sygnałem ataku i limit pozwala go ograniczyć, zanim przeciąży system.
Macie integracje z ERP, BaseLinkerem czy systemem płatności, których bezpieczeństwo nikt nie sprawdzał od dawna? Sprawdźcie naszą ofertę cyberbezpieczeństwa — zaudytujemy Wasze integracje API i webhooki, zanim zrobi to za Was ktoś niepowołany.
