¿Qué tan peligroso es permitir que se publiquen URLs webhook arbitrarias?

10

Estoy creando una API de Ruby on Rails que publica en webhooks que el usuario de la API puede crear, cada vez que se crea, actualiza o destruye un recurso que él administra, utilizando gema HTTParty . Esto me hizo pensar: estoy validando que la URL de webhook es de hecho una URL válida, pero eso es todo.

¿Qué pasa si, por ejemplo, la API publica en un webhook que redirige para siempre? O, tal vez incluso peor, un webhook que a su vez se comunica con la API nuevamente, lo que genera más webhooks, de modo que eventualmente la API tiene que manejar una cantidad infinita de webhooks.

Estos son solo dos ejemplos, pero creo que podrían suceder muchas más.

Lo único que se me ha ocurrido es poner todas las publicaciones en webhooks en tareas en segundo plano, para que al menos la carga de trabajo se distribuya a los trabajadores, en caso de que alguien intente un ataque de DOS (pero, de nuevo, no estoy seguro si que me protege adecuadamente de los ataques de DOS).

¿Existen otras amenazas / inconvenientes comunes al utilizar webhooks? ¿Qué puedo hacer para defenderme de webhooks dañinos y cómo puedo detectarlos?

    
pregunta weltschmerz 23.12.2013 - 14:13
fuente

3 respuestas

4

Además de "validar las URL de webhook", implemente la limitación de velocidad en los puntos finales de su API y / o llame a los webhooks.

Si tienes un servicio lo suficientemente grande / popular, deberías tenerlo incluso si no permites que los usuarios tengan URL de devolución de llamada personalizadas. Eventualmente, alguien intentará hacer un millón de solicitudes contra un extremo de API que requiere muchos recursos (para ti). , y realmente deberías tener protección en su lugar.

Es decir, no es necesario que intentes detectar a fondo las URL "maliciosas", solo debes tener una lógica que impida el acceso si una sola cuenta realiza X solicitudes dentro de Y minutos (agrega lógica más compleja según sea necesario).

——

Por supuesto que también deberías:

  • ejecuta webhooks de forma asíncrona (en segundo plano) para que la velocidad de tu API no dependa de un tercero.
  • ejecute comprobaciones básicas que impidan infinitos bucles de redireccionamiento y (por ejemplo) incluya en su lista negra su propio dominio (asegúrese de verificar la lista negra para cada destino de redireccionamiento por separado).
respondido por el Joel L 24.12.2013 - 00:05
fuente
3

Todas estas preocupaciones son muy válidas y hemos tenido que considerarlas al escribir la PubSubHubbub spec . "Resolvimos" la mayoría de ellos mediante un paso de verificación que implica ejecutar el webhook y esperar una respuesta específica de este. Básicamente, cuando se agrega un nuevo enlace, se le llama con una solicitud GET y un parámetro 'hub.challenge' adicional. El webhook entonces DEBE responder con un 200 y hacer eco del hub.challenge en el cuerpo.

En general, recomiendo consultar PubSubHubbub al implementar una "API" de webhooks, porque eso es lo que es :) Inicialmente, fue diseñado para RSS / Atom pero ahora funciona con cualquier tipo de recursos, incluyendo JSON. También proporciona mecanismos para la entrega segura (utilizando firmas secretas y HMAC).

    
respondido por el Julien Genestoux 26.12.2013 - 11:01
fuente
2

Bajando esto del comentario porque es importante.

Una preocupación para abordar también es objetivos internos. Por ejemplo, un atacante podría pasar una dirección que sea interna a su red y que normalmente tendría un firewall desactivado y / u oculto detrás de NAT. Las implicaciones de esto varían enormemente según su aplicación.

Considere también la posibilidad de acceder a recursos de infraestructura como AWS S3, bases de datos de Dynamo DB o colas SQS. Dependiendo de su configuración, podría permitir escrituras arbitrarias a estos recursos. Dependiendo de su configuración, puede ser posible que un atacante lea / escriba datos en / desde uno de estos servicios, y luego haga que esos datos se filtren mediante un webhook regenerativo (desencadene otro webhook que haría eco de estos datos) de vuelta a su propio servidor!

Esto es algo que se debe tener en cuenta al validar las URL de webhook.

    
respondido por el Freedom_Ben 23.02.2017 - 20:07
fuente

Lea otras preguntas en las etiquetas