Dlaczego fałszywe alarmy Sucuri WAF nadal blokowały webhooki Stripe i poprawka precyzyjnej białej listy adresów IP, która to zatrzymała

Opublikowany: 2025-11-13

Firmy korzystające ze Stripe w transakcjach online wiedzą, jak ważna jest płynna komunikacja webhook. Kiedy jednak Sucuri, popularna zapora sieciowa dla aplikacji internetowych (WAF), zaczyna błędnie identyfikować legalne webhooki Stripe jako zagrożenia, rezultatem mogą być zakłócenia w płatnościach, nieudane transakcje i niepotrzebne koszty obsługi klienta. Jeśli zmagasz się z tym frustrującym scenariuszem, nie jesteś sam — i na szczęście istnieje dokładne rozwiązanie.

TL;DR

Jeśli Twoje webhooki Stripe są blokowane przez Sucuri WAF z powodu fałszywych alarmów, problem często wynika z niewłaściwego dodania białej listy adresów IP lub nadgorliwych reguł WAF. Serwery Stripe zmieniają się pod różnymi adresami IP, co musi być wyraźnie dozwolone w ustawieniach WAF. Aktualizując zaporę Sucuri za pomocą oficjalnych adresów IP Stripe i wyłączając określone reguły heurystyczne, możesz natychmiast rozwiązać problem i przywrócić płynne działanie webhooka.

Zrozumienie problemu: Sucuri WAF i fałszywe alarmy

Sucuri zapewnia solidną ochronę przed atakami DDoS, włamaniami do stron internetowych i innymi złośliwymi działaniami. Działa poprzez sprawdzanie przychodzących żądań HTTP i blokowanie wszystkiego, co wygląda choć trochę podejrzanie. Chociaż jest to doskonałe rozwiązanie do blokowania złych aktorów, może przynieść odwrotny skutek, gdy legalne usługi, takie jak Stripe, wysyłają wywołania webhooka.

Stripe używa webhooków do powiadamiania Twojego serwera o ważnych zdarzeniach — takich jak udane płatności, nieudane transakcje, zwroty pieniędzy i zmiany w subskrypcji. Są one niezbędne do automatyzacji procesów, takich jak aktualizacja danych klientów, zarządzanie zapasami i śledzenie przychodów.

Problem pojawia się, gdy reguły Sucuri — zwłaszcza filtry heurystyczne próbujące wykryć wstrzyknięcie kodu SQL lub wstrzyknięcie kodu — błędnie klasyfikują ładunki webhooka Stripe jako złośliwe.

Typowe objawy tego problemu obejmują:

Panel Stripe pokazuje powtarzające się błędy w dostarczaniu elementu webhook.
W logach serwera nie widać żadnych przychodzących żądań POST od Stripe.
Stripe ponawia żądania wielokrotnie z powodu błędu 403 Forbidden lub przekroczenia limitu czasu.
Powiadomienia e-mail od Stripe ostrzegające o awarii webhooka.

Mimo że Sucuri chroni Twoją witrynę, może działać nieco zbyt agresywnie — blokując to, czego nie powinna.

Identyfikacja pierwotnej przyczyny: fałszywe alarmy wywołane przez Stripe

Kiedy zagłębiliśmy się w logi serwera i pulpit Sucuri, problem stał się jaśniejszy. Każdy webhook Stripe otrzymywał odpowiedź 403 Forbidden lub całkowicie blokowano mu dostęp do serwera. Przeglądając dzienniki incydentów w Sucuri, wielokrotnie wyzwalane były następujące flagi:

Wzorzec heurystyczny SQLi
Żądanie rozmiaru ciała przekroczyło próg
Żądanie POST zablokowane z powodu nieprawidłowego formatu JSON(nawet jeśli JSON był prawidłowy)

Sucuri wykorzystuje ewoluujący algorytm wykrywania, a czasami ładunki JSON Stripe zawierają znaki lub wzorce (takie jak cudzysłowy, nawiasy lub określone słowa kluczowe), które te silniki heurystyczne błędnie interpretują jako podejrzane działanie. Powoduje to, że Sucuri oznacza i odrzuca żądanie, uniemożliwiając mu dotarcie do Twojej aplikacji.

Było to szczególnie problematyczne podczas kampanii promocyjnych, kiedy duże wolumeny transakcji powodowały zalew webhooków, z których wiele nie prowadziło donikąd.

Właściwa poprawka: precyzyjne umieszczanie na białej liście adresów IP

Chociaż kuszące jest tymczasowe wyłączenie zapory sieciowej lub dodanie całego świata do białej listy adresów URL elementów webhook, jest to koszmar związany z bezpieczeństwem. Prawidłowa i bezpieczna poprawka obejmuje kilka strategicznych kroków:

1. Uzyskaj oficjalne adresy IP Stripe

Stripe publikuje listę zakresów adresów IP, z których pochodzą ich webhooki. Lista ta jest dostępna w ich oficjalnej dokumentacji i jest regularnie aktualizowana.

W chwili pisania tego tekstu oto przykładowe adresy IP (UWAGA: te zmiany, zawsze sprawdzaj oficjalne źródło):

3.18.12.63
3.130.192.231
13.235.14.237
13.235.122.149
18.211.135.69
35.154.171.200
52.15.183.38

2. Zaloguj się do Panelu Sucuri

Przejdź do ustawień zapory sieciowej Sucuri i znajdź sekcję Biała lista w obszarze Kontrola dostępu. Tutaj możesz ręcznie wprowadzić dokładne adresy IP, na które chcesz zezwolić, pomijając wszystkie kontrole WAF.

3. Dodaj wszystkie adresy IP Stripe do białej listy

Upewnij się, że każdy blok IP dostarczony przez Stripe jest dodany do białej listy. Sucuri wykonuje trudne dopasowanie, więc brak choćby jednego adresu IP może skutkować sporadyczną awarią losowych zdarzeń webhooka.

4. Wyłącz zablokowane akcje dla punktu końcowego webhooka

Wkonfiguracji ścieżek URLSucuri możesz dodać punkt końcowy odbiornika webhooka (np. /stripe/webhook) i wyłączyć określone reguły WAF tylko dla tej ścieżki. Pozwala to uniknąć globalnego wyłączania zapory sieciowej, zapewniając jednocześnie, że żądania Stripe nie będą niepotrzebnie blokowane. Najbardziej pomocnym ustawieniem jest:

Wyłącz filtrowanie heurystyczne dla tej konkretnej ścieżki.
Zezwalaj na większe rozmiary treści POST, jeśli zdarzenia Stripe zawierają ładunki zawierające duże ilości metadanych.

Dzięki temu punkt końcowy będzie akceptował złożone ładunki JSON bez zakłóceń.

Dodatkowa wskazówka: użyj sekretu podpisywania Stripe'a

Nawet po umieszczeniu adresów IP Stripe na białej liście nadal mądrze jest weryfikować autentyczność każdego otrzymanego żądania webhooka. Stripe udostępnia sekret podpisywania, który umożliwia serwerowi kryptograficzną weryfikację ładunków webhooka.

Dzięki temu nawet jeśli inne źródło sfałszuje adresy IP Stripe i trafi na adres URL Twojego webhooka (mało prawdopodobne, ale możliwe), jego żądania nie przejdą weryfikacji podpisu. Postępuj zgodnie z przewodnikiem Stripe tutaj, aby go wdrożyć.

Wpływ: jakie rozwiązanie w zakresie prawidłowego umieszczania na białej liście

Po skonfigurowaniu wszystkich adresów IP Stripe w zaporze Sucuri i dostrojeniu zachowania reguł WAF dla punktu końcowego webhooka problem całkowicie zniknął. Webhooki zaczęły być natychmiast potwierdzane, mechanizm ponawiania prób Stripe nie był już aktywny i żadne zdarzenia nie zostały utracone.

Pod względem przepływu pracy i doświadczenia użytkownika —

Klienci przestali widzieć opóźnienia w potwierdzeniach płatności.
Zgłoszenia do pomocy technicznej dotyczące nieudanych subskrypcji zostały usunięte.
Automatyzacje zaplecza, takie jak tworzenie nowego konta użytkownika, znów działały niezawodnie.

Uwaga na temat automatyzacji

Ponieważ lista adresów IP Stripe może ewoluować, dobrym pomysłem jest ustawienie kwartalnego przypomnienia w kalendarzu w celu sprawdzenia dostępności aktualizacji. Niestety Sucuri nie oferuje automatyzacji białych list opartej na API, więc proces pozostaje ręczny. Bycie proaktywnym w tej kwestii jest niezbędne, jeśli chcesz uniknąć kolejnej rundy nieudanej dostarczalności webhooka.

Ostatnie przemyślenia

Sucuri WAF to potężne narzędzie do zabezpieczania witryn internetowych, ale żaden system bezpieczeństwa nie jest niezawodny. Fałszywe alarmy, zwłaszcza w przypadku legalnych usług, takich jak Stripe, mogą powodować prawdziwe tarcia biznesowe. Uzbrojeni w odpowiednie adresy IP i odrobinę dostosowywania reguł WAF, możesz zapewnić usprawnienie i bezpieczeństwo przetwarzania płatności.

Pamiętaj:bezpieczeństwo nie musi odbywać się kosztem funkcjonalności. Dzięki starannej konfiguracji możesz zachować jedno i drugie w harmonii.