Perché i falsi positivi WAF di Sucuri continuavano a bloccare i webhook Stripe e la correzione precisa della whitelist IP che lo ha fermato

Le aziende che si affidano a Stripe per le transazioni online conoscono l'importanza di una comunicazione webhook senza soluzione di continuità. Ma quando Sucuri, un popolare firewall per applicazioni web (WAF), inizia a identificare erroneamente i webhook Stripe legittimi come minacce, il risultato può essere un’interruzione dei pagamenti, transazioni non riuscite e spese generali non necessarie per l’assistenza clienti. Se hai lottato con questo scenario frustrante, non sei il solo e, per fortuna, esiste una soluzione precisa.

TL;DR

Se i tuoi webhook Stripe vengono bloccati da Sucuri WAF a causa di falsi positivi, il problema spesso deriva da una whitelist IP impropria o da regole WAF troppo zelanti. I server di Stripe ruotano attraverso vari IP che devono essere esplicitamente consentiti nelle impostazioni WAF. Aggiornando il tuo firewall Sucuri con gli indirizzi IP ufficiali di Stripe e disabilitando regole euristiche specifiche, puoi risolvere immediatamente il problema e ripristinare la funzionalità regolare del webhook.

Comprendere il problema: Sucuri WAF e falsi positivi

Sucuri fornisce una solida difesa contro attacchi DDoS, attacchi ai siti Web e altre attività dannose. Funziona esaminando le richieste HTTP in entrata e bloccando tutto ciò che sembra remotamente sospetto. Anche se questo è eccellente per bloccare i malintenzionati, può rivelarsi controproducente quando servizi legittimi come Stripe inviano chiamate webhook.

Stripe utilizza webhook per notificare al tuo server eventi significativi, come pagamenti riusciti, transazioni non riuscite, rimborsi e modifiche dell'abbonamento. Questi sono essenziali per automatizzare processi come l'aggiornamento dei record dei clienti, la gestione dell'inventario e il monitoraggio delle entrate.

Il problema sorge quando le regole di Sucuri, in particolare i filtri euristici che tentano di rilevare l'iniezione SQL o l'iniezione di codice, classificano erroneamente i payload webhook di Stripe come dannosi.

I sintomi comuni di questo problema includono:

• La dashboard di Stripe mostra ripetuti errori di consegna del webhook.
• Nessuna richiesta POST in entrata da Stripe visibile nei log del server.
• Stripe ritenta le richieste più volte a causa di errori 403 Forbidden o timeout.
• Notifiche e-mail da Stripe che avvisano dell'errore del webhook.

Anche se Sucuri protegge il tuo sito, potrebbe finire per agire in modo un po’ troppo aggressivo, bloccando ciò che non dovrebbe.

Identificazione della causa principale: falsi positivi innescati da Stripe

Quando abbiamo approfondito i log del server e la dashboard di Sucuri, il problema è diventato più chiaro. Ogni webhook Stripe riceveva una risposta 403 Forbidden o veniva completamente bloccato nel raggiungere il server. Visualizzando i registri degli incidenti in Sucuri, sono stati ripetutamente attivati ​​i seguenti flag:

• Modello euristico SQLi
• La dimensione corporea richiesta ha superato la soglia
• Richiesta POST bloccata a causa di un JSON non valido(anche quando JSON era valido)

Sucuri utilizza un algoritmo di rilevamento in evoluzione e talvolta i payload JSON di Stripe includono caratteri o modelli (come virgolette, parentesi o determinate parole chiave) che questi motori euristici interpretano erroneamente algoritmicamente come attività sospette. Ciò fa sì che Sucuri contrassegni e rilasci la richiesta, senza mai consentirle di raggiungere la tua applicazione.

Ciò era particolarmente problematico durante le campagne promozionali, quando grandi volumi di transazioni creavano un’ondata di webhook, molti dei quali non andavano da nessuna parte.

La soluzione corretta: whitelist IP precisa

Sebbene sia forte la tentazione di disabilitare temporaneamente il firewall o di inserire nella whitelist il mondo intero per gli URL webhook, questo è un incubo per la sicurezza. La soluzione corretta e sicura prevede alcuni passaggi strategici:

1. Recupera gli indirizzi IP ufficiali di Stripe

Stripe pubblica un elenco di intervalli IP da cui provengono i relativi webhook. Questo elenco è disponibile dalla loro documentazione ufficiale e viene regolarmente aggiornato.

Al momento della stesura, ecco alcuni IP di esempio (NOTA: questi cambiano, controlla sempre la fonte ufficiale):

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. Accedi alla dashboard di Sucuri

Vai alle impostazioni del tuo firewall Sucuri e individua la sezione Whitelist sotto Controllo accesso. Qui puoi inserire manualmente gli IP esatti a cui desideri consentire il passaggio, ignorando tutti i controlli WAF.

3. Aggiungi tutti gli IP di Stripe alla Whitelist

Assicurati che ogni singolo blocco IP fornito da Stripe venga aggiunto alla whitelist. Sucuri esegue una corrispondenza difficile, quindi la mancanza anche di un IP può comportare il fallimento intermittente di eventi webhook casuali.

4. Disabilitare le azioni bloccate per l'endpoint webhook

Nellaconfigurazione dei percorsi URLdi Sucuri, puoi aggiungere il tuo endpoint listener webhook (ad esempio, /stripe/webhook) e disabilitare regole WAF specifiche solo per quel percorso. Ciò evita di disattivare il firewall a livello globale garantendo al tempo stesso che le richieste di Stripe non vengano bloccate inutilmente. L'impostazione più utile qui è:

• Disabilita il filtro euristico per quel percorso specifico.
• Consenti dimensioni del corpo POST più grandi se i tuoi eventi Stripe includono payload ricchi di metadati.

Ciò garantirà che l'endpoint accetti payload JSON complessi senza interferenze.

Suggerimento bonus: utilizza il segreto di firma di Stripe

Anche dopo aver inserito nella whitelist gli IP di Stripe, è comunque intelligente verificare l'autenticità di ogni richiesta webhook ricevuta. Stripe fornisce un segreto di firma che consente al tuo server di verificare crittograficamente i payload del webhook.

Ciò aiuta a garantire che anche se qualche altra fonte falsificasse gli IP di Stripe e colpisse l'URL del tuo webhook (improbabile, ma possibile), le loro richieste fallirebbero la verifica della firma. Segui la guida di Stripe qui per implementarlo.

L'impatto: cosa è stato risolto con la corretta whitelist

Dopo aver configurato tutti gli IP di Stripe all'interno del firewall Sucuri e aver ottimizzato il comportamento delle regole WAF per l'endpoint webhook, il problema è scomparso completamente. I webhook hanno iniziato a essere riconosciuti immediatamente, il meccanismo di nuovo tentativo di Stripe non era più attivo e nessun evento è andato perso.

In termini di flusso di lavoro ed esperienza utente:

• I clienti hanno smesso di vedere conferme di pagamenti ritardati.
• I ticket di supporto relativi agli abbonamenti non riusciti sono stati eliminati.
• Le automazioni di backend, come la creazione di nuovi account utente, hanno funzionato di nuovo in modo affidabile.

Una nota sull'automazione

Poiché l'elenco degli IP di Stripe può evolversi, è una buona idea impostare un promemoria del calendario trimestrale per verificare la presenza di aggiornamenti. Sfortunatamente, Sucuri non offre l'automazione della whitelist basata su API, quindi il processo rimane manuale. Essere proattivi al riguardo è fondamentale se si desidera evitare un altro ciclo di consegna fallita del webhook.

Considerazioni finali

Sucuri WAF è un potente strumento per proteggere le tue proprietà web, ma nessun sistema di sicurezza è infallibile. I falsi positivi, soprattutto su servizi legittimi come Stripe, possono causare reali attriti aziendali. Armato degli IP giusti e di un po' di personalizzazione delle regole WAF, puoi mantenere l'elaborazione dei pagamenti semplificata e sicura.

Ricorda:la sicurezza non deve necessariamente andare a scapito della funzionalità. Con un'attenta configurazione, puoi mantenere entrambi in armonia.