Por qué los falsos positivos de Sucuri WAF siguieron bloqueando los webhooks de Stripe y la solución precisa de la lista blanca de IP que lo detuvo

Las empresas que confían en Stripe para transacciones en línea conocen la importancia de una comunicación fluida mediante webhook. Pero cuando Sucuri, un popular firewall de aplicaciones web (WAF), comienza a identificar erróneamente los webhooks legítimos de Stripe como amenazas, el resultado puede ser la interrupción de los pagos, transacciones fallidas y gastos innecesarios de atención al cliente. Si ha estado luchando con esta situación frustrante, no está solo y, afortunadamente, existe una solución precisa.

TL;DR

Si Sucuri WAF bloquea sus webhooks de Stripe debido a falsos positivos, el problema a menudo surge de una lista blanca de IP inadecuada o de reglas WAF demasiado entusiastas. Los servidores de Stripe rotan a través de varias IP que deben estar permitidas explícitamente en su configuración de WAF. Al actualizar su firewall Sucuri con las direcciones IP oficiales de Stripe y deshabilitar reglas heurísticas específicas, puede resolver instantáneamente el problema y restaurar la funcionalidad del webhook sin problemas.

Comprender el problema: Sucuri WAF y falsos positivos

Sucuri proporciona una sólida defensa contra ataques DDoS, ataques a sitios web y otras actividades maliciosas. Funciona examinando las solicitudes HTTP entrantes y bloqueando cualquier cosa que parezca remotamente sospechosa. Si bien esto es excelente para bloquear a los malos actores, puede resultar contraproducente cuando servicios legítimos como Stripe envían llamadas de webhook.

Stripe utiliza webhooks para notificar a su servidor sobre eventos importantes, como pagos exitosos, transacciones fallidas, reembolsos y cambios de suscripción. Estos son esenciales para automatizar procesos como la actualización de registros de clientes, la gestión de inventario y el seguimiento de ingresos.

El problema surge cuando las reglas de Sucuri (especialmente los filtros heurísticos que intentan detectar la inyección de SQL o de código) clasifican erróneamente las cargas útiles del webhook de Stripe como maliciosas.

Los síntomas comunes de este problema incluyen:

• El panel de Stripe muestra fallas repetidas en la entrega de webhooks.
• No hay solicitudes POST entrantes de Stripe visibles en los registros del servidor.
• Stripe reintenta las solicitudes varias veces debido a errores 403 prohibidos o de tiempo de espera.
• Notificaciones por correo electrónico de Stripe que advierten sobre fallas en el webhook.

Aunque Sucuri esté protegiendo su sitio, puede terminar actuando de manera demasiado agresiva, bloqueando lo que no debería.

Identificación de la causa raíz: falsos positivos provocados por Stripe

Cuando profundizamos en los registros del servidor y el panel de Sucuri, el problema se volvió más claro. Cada webhook de Stripe recibía una respuesta 403 Forbidden o se le impedía llegar al servidor. Al ver los registros de incidentes en Sucuri, se activaron repetidamente las siguientes banderas:

• Patrón heurístico SQLi
• El tamaño del cuerpo de la solicitud superó el umbral
• Solicitud POST bloqueada debido a JSON con formato incorrecto(incluso cuando el JSON era válido)

Sucuri utiliza un algoritmo de detección en evolución y, a veces, las cargas útiles JSON de Stripe incluyen caracteres o patrones (como comillas, corchetes o ciertas palabras clave) que estos motores heurísticos malinterpretan algorítmicamente como actividad sospechosa. Esto hace que Sucuri marque y descarte la solicitud, sin permitir nunca que llegue a su aplicación.

Esto fue especialmente problemático durante las campañas promocionales, cuando grandes volúmenes de transacciones crearon una avalancha de webhooks, muchos de los cuales no llegaron a ninguna parte.

La solución adecuada: listas blancas de IP precisas

Si bien es tentador simplemente desactivar temporalmente el firewall o incluir en la lista blanca a todo el mundo para las URL de webhooks, eso es una pesadilla de seguridad. La solución correcta y segura implica algunos pasos estratégicos:

1. Recupera las direcciones IP oficiales de Stripe

Stripe publica una lista de rangos de IP desde los que se originan sus webhooks. Esta lista está disponible en su documentación oficial y se actualiza periódicamente.

Al momento de escribir este artículo, aquí hay ejemplos de IP (NOTA: estas cambian, consulte siempre la fuente oficial):

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. Inicie sesión en el Panel de Sucuri

Vaya a la configuración de su firewall Sucuri y ubique la sección Lista blanca en Control de acceso. Aquí, puede ingresar manualmente las IP exactas que desea permitir, evitando todas las comprobaciones WAF.

3. Agregue todas las IP de Stripe a la lista blanca

Asegúrese de que cada bloque de IP proporcionado por Stripe se agregue a la lista blanca. Sucuri hace una coincidencia difícil, por lo que perder incluso una IP puede provocar que eventos de webhook aleatorios fallen de forma intermitente.

4. Deshabilite las acciones bloqueadas para Webhook Endpoint

Enla configuración de rutas URLde Sucuri, puede agregar su punto final de escucha de webhook (por ejemplo, /stripe/webhook) y deshabilitar reglas WAF específicas solo para esa ruta. Esto evita apagar el firewall globalmente y al mismo tiempo garantiza que las solicitudes de Stripe no se bloqueen innecesariamente. La configuración más útil aquí es:

• Deshabilite el filtrado heurístico para esa ruta específica.
• Permita tamaños de cuerpo POST más grandes si sus eventos de Stripe incluyen cargas útiles con muchos metadatos.

Esto garantizará que el punto final acepte cargas útiles JSON complejas sin interferencias.

Consejo adicional: utilice el secreto de firma de Stripe

Incluso después de incluir las IP de Stripe en la lista blanca, sigue siendo inteligente verificar la autenticidad de cada solicitud de webhook recibida. Stripe proporciona un secreto de firma que permite a su servidor verificar criptográficamente las cargas útiles del webhook.

Esto ayuda a garantizar que incluso si alguna otra fuente falsificara las IP de Stripe y accediera a la URL de su webhook (poco probable, pero posible), sus solicitudes no pasarían la verificación de firma. Siga la guía de Stripe aquí para implementarlo.

El impacto: lo que resolvió la lista blanca correcta

Después de configurar todas las IP de Stripe dentro del firewall de Sucuri y ajustar el comportamiento de las reglas WAF para el punto final del webhook, el problema desapareció por completo. Los webhooks comenzaron a ser reconocidos instantáneamente, el mecanismo de reintento de Stripe ya no estaba activo y no se perdió ningún evento.

En términos de flujo de trabajo y experiencia de usuario:

• Los clientes dejaron de ver confirmaciones de pago retrasadas.
• Se eliminaron los tickets de soporte sobre suscripciones fallidas.
• Las automatizaciones de backend, como la creación de nuevas cuentas de usuario, volvieron a funcionar de manera confiable.

Una nota sobre la automatización

Dado que la lista de IP de Stripe puede evolucionar, es una buena idea establecer un recordatorio trimestral en el calendario para buscar actualizaciones. Desafortunadamente, Sucuri no ofrece automatización de listas blancas basada en API, por lo que el proceso sigue siendo manual. Ser proactivo al respecto es vital si desea evitar otra ronda de entrega fallida de webhooks.

Pensamientos finales

Sucuri WAF es una herramienta poderosa para mantener seguras sus propiedades web, pero ningún sistema de seguridad es infalible. Los falsos positivos, especialmente en servicios legítimos como Stripe, pueden causar fricciones comerciales reales. Armado con las IP correctas y un poco de personalización de las reglas WAF, puede mantener el procesamiento de pagos optimizado y seguro.

Recuerde:la seguridad no tiene por qué ir a expensas de la funcionalidad. Con una configuración cuidadosa, puedes mantener ambos en armonía.