Webhooks: Lo bueno, lo malo y lo feo

Webhooks 101

En su nivel más básico, un webhook es un mensaje que un sistema envía a otro para hacerle saber que algo ha cambiado en el primero. Ese sistema receptor o escucha procesa el webhook y responde. Ni el emisor ni el receptor tienen que tener un lenguaje de programación, una pila tecnológica o incluso un entorno de alojamiento comunes.

El concepto subyacente fue propuesto por Jeff Lindsay, que acuñó el término y lo popularizó a partir de 2007. Lindsay lo relacionó con el antiguo principio orientado a objetos del “paso de mensajes”.

En el paso de mensajes, los objetos comunican cambios en su estado interno, mientras que otros objetos del sistema pueden escuchar y actuar según sea necesario. El concepto subyacente sigue siendo válido, pero hemos pasado de un sistema en memoria orientado a objetos a una red global.

Volviendo a nuestra implementación moderna, el webhook en sí suele ser una carga JSON a través de HTTPS. La aplicación que escucha lo recibe, lo procesa y da una respuesta. Dentro de la escucha, puede registrar el evento, iniciar un flujo de trabajo o incluso no hacer nada en absoluto. A nosotros no nos importa, y al mecanismo de webhook tampoco.

Lo único que nos importa es que el servicio de webhooks publicó un cambio de estado, y la aplicación que escucha recogió ese cambio y envió una respuesta.

Por qué los desarrolladores adoran los webhooks:

• Todo ocurre a través de Internet mediante HTTP.
• Utilizan una carga útil sencilla como JSON o XML.
• Funcionan con cualquier pila tecnológica, por lo que los desarrolladores no tienen que depender de proveedores.
• Permiten compartir cambios de estado entre sistemas.
• Son fáciles de probar y simular (por ejemplo, podemos crear cosas parecidas para probarlas).

El fallo fatal

El error fatal de los webhooks es que tenemos tres componentes independientes: el sistema generador o emisor, la aplicación que escucha y el canal de comunicación entre ellos. Al considerar cómo aseguramos los webhooks, tenemos que pensar en los tres componentes.

Si estás creando tus propias aplicaciones de origen, tienes control sobre los tres. Por desgracia, la gran mayoría de nosotros sólo tiene control sobre dos de los tres. El tercer componente es opaco desde nuestra perspectiva.

Por lo tanto, cuando pensamos en cómo estamos construyendo webhooks, tenemos que adoptar una perspectiva defensiva. Si estás construyendo la aplicación de escucha, necesitas protegerte de atacantes en el canal de comunicaciones que intercepten, adapten o incluso reproduzcan los webhooks. Si eres el sistema de difusión, necesitas protegerte

Riesgos del uso de webhooks

Si sólo tienes control sobre el servicio generador o la app que escucha, no puedes confiar intrínsecamente en la otra app o en el canal. Debes considerar proactivamente qué riesgos existen y con qué puedes atacarlos. Los riesgos incluyen:

• Interceptar o espiar las cargas útiles
• Hacerse pasar por la app emisora
• Modificar o manipular las cargas útiles
• Repetición de solicitudes: si la primera solicitud era legítima, el receptor asumirá que la misma solicitud también lo es.
• Falta de solicitudes
• Apoyar la compatibilidad futura a medida que cambian los requisitos de seguridad

Buenas prácticas para los proveedores de Webhooks

Los webhooks son la piedra angular del desarrollo de productos modernos. Si proporcionas webhooks, es tu responsabilidad asegurarte de que los haces lo más seguros posible. He aquí algunas prácticas recomendadas.

1. Utiliza HTTPS: no hay excusa para no hacerlo. Organizaciones como Let’s Encrypt hacen que la gestión de certificados sea un proceso rápido y sencillo. Utilízalo.
2. Proporciona documentación y ejemplos que demuestren el enfoque seguro y adecuado para utilizar tus webhooks. Los proveedores deben mostrar el flujo completo del webhook, incluidos todos los parámetros, URL y opciones que puede ver un usuario. Si quieres puntos extra, muestra todas las cargas útiles para que el usuario sepa qué esperar. Y por último, demuestra la verificación con código de muestra e incrusta esa verificación en tus bibliotecas.
3. Firma tu carga útil para protegerla de posibles modificaciones. Si utilizas un secreto compartido, HMAC, ESA/ECDSA, JWT/JWK/OAuth, o mTLS, cualquiera de ellos son enfoques razonables de complejidad variable, pero HMAC se ha convertido en el estándar de facto.
   métodos de autenticación webhook
4. Mitiga los ataques de respuesta utilizando marcas de tiempo o ID de solicitud en la verificación de la firma. Al incluir la marca de tiempo, los sistemas de escucha pueden elegir cuánto tiempo aceptar una solicitud determinada y rechazar las solicitudes antiguas. Alternativamente, se puede utilizar un ID de solicitud y hacer un seguimiento para asegurarse de que cada una es única, rechazando las solicitudes que haya visto antes. Elijas el método que elijas, asegúrate de que se incluye en la firma para que tampoco pueda modificarse.
5. Utiliza el soporte multiversión. Cuando tengas un cambio de versión, crea una nueva firma que lo comunique claramente y la incluya en la carga útil. Si tienes varias firmas en la carga útil, el usuario final entenderá que puede utilizar cualquiera de esas versiones y que puedes actualizar de forma transparente sin romper sus sistemas.
6. Rota las claves e inclúyelas en tu firma para conseguir un tiempo de inactividad cero.

Mejorando la seguridad de los webhooks verificando las firmas

Aunque los webhooks nos dan potencia y flexibilidad, también requieren una conexión en directo a la Internet pública. Sin buenos controles de seguridad, terceros podrían explorar los webhooks para actividades maliciosas, como enviar eventos falsos para contaminar tus sistemas, obtener información confidencial, corromper tus datos o enviar spam a los usuarios.

Por suerte, muchos proveedores de webhooks ofrecen capacidades para verificar el remitente, validar los datos enviados e incluso mitigar ataques más específicos.

En ngrok, hemos desarrollado un módulo para verificar las firmas de los webhooks en la conexión mucho antes de que el tráfico llegue a tu aplicación. Esto no sólo te ahorra tiempo de modificar tu aplicación, sino que también puedes proteger esas aplicaciones heredadas que temes tocar.

Tras explorar más de 100 proveedores de webhooks y crear soporte para más de 70, hemos recopilado los patrones más comunes, interesantes y desafiantes. Consulta las conclusiones de la investigación en el blog de ngrok.