Resumen
Fizzy es una aplicación de Basecamp que organiza el trabajo en tarjetas, y a esas tarjetas se les pueden adjuntar ficheros. El investigador perxibes vio que, en https://app.fizzy.do/, esos adjuntos y sus vistas previas se entregaban a través de URLs de Active Storage (el sistema de ficheros de Rails) sin ninguna comprobación de autenticación ni de autorización.
Bastaba con tener la URL de un adjunto para abrirlo, aunque no se hubiera iniciado sesión o se estuviera conectado con otra cuenta. El reporte está clasificado como IDOR (referencia directa insegura a objetos), con severidad baja. El programa pagó recompensa, aunque no ha hecho público el importe. Se envió el 16 de diciembre de 2025 y se divulgó el 16 de marzo de 2026.
Pasos de reproducción
- Iniciar sesión en
https://app.fizzy.do/con una cuenta (usuario A). - Adjuntar un fichero a una tarjeta.
- Abrir el adjunto para que la página muestre su vista previa o el enlace de descarga.
- Copiar desde el navegador la URL de Active Storage de ese recurso (la de la imagen de vista previa o la del enlace de descarga).
- Abrir una sesión nueva del navegador sin iniciar sesión, o entrar con otro usuario.
- Pegar la URL en la barra de direcciones.
El fichero o su vista previa se muestran sin problema.
Impacto
Quien tenga la URL ve el adjunto aunque no tenga sesión ni permiso sobre el recurso original. El investigador subraya dos cosas:
- No hace falta adivinar ni probar URLs a fuerza bruta: la propia aplicación las expone durante el uso normal, en el HTML de la página y en las peticiones que hace el navegador.
- Pasaba con varios tipos de fichero: PDF, imágenes, texto y HTML.
En la práctica, cualquier URL de un adjunto que acabe en manos de otra persona (por ejemplo, pegada en un chat o guardada en el historial de un equipo compartido) permite leerlo fuera del modelo de permisos de Fizzy. Según el investigador, el problema está en cómo la aplicación configura o usa Active Storage, no en un fallo del propio Rails.
Remediación
El reporte figura como resuelto, pero no explica qué se cambió.
Qué aprender de este caso
- Si una aplicación Rails sirve ficheros por rutas como
/rails/active_storage/blobs/...o/rails/active_storage/representations/..., copia una de esas URLs y ábrela en una ventana privada o con otra cuenta: los controladores que Rails trae por defecto no conocen los permisos de la aplicación. - Prueba por separado las vistas previas y las descargas: cada una tiene su propia URL y una aplicación puede proteger una y dejar la otra abierta.
- Al programar, sirve los adjuntos privados con un controlador propio que compruebe si el usuario tiene acceso al registro dueño del fichero (aquí, la tarjeta) antes de entregarlo o redirigir al almacenamiento. Si se usan URLs firmadas, que caduquen pronto, sabiendo que cualquiera que tenga una puede usarla hasta entonces.
- Que una URL sea larga y difícil de adivinar no es un control de acceso si la aplicación la pone en el HTML: cualquiera que vea la página o reciba el enlace puede reutilizarla.