Reports
BAJA[LÓGICA DE NEGOCIO]#3485178

Nextcloud Deck acepta cualquier texto como color de etiqueta y deja inutilizable la gestión de etiquetas del tablero

La API de etiquetas de Nextcloud Deck no validaba el parámetro color. Cualquier miembro de un tablero podía guardar un valor arbitrario y dejar las etiquetas sin mostrarse ni gestionarse para todos los usuarios.

Resumen
Resumen en castellano de un reporte público, no una traducción literal. El código y los comandos se mantienen como en el original.

Resumen

Deck es la app de tableros de Nextcloud. Cada tablero tiene etiquetas, cada una con un título y un color. El endpoint que las crea, POST /apps/deck/labels, guardaba sin comprobarlo lo que llegase en el parámetro color. Se suponía que solo admitía colores válidos (los predefinidos o un HEX), pero aceptaba cualquier cadena y respondía 200 OK.

El problema venía de un desajuste entre las dos partes de la aplicación: el backend guardaba el valor y el frontend no sabía qué hacer con él. Si una sola etiqueta tenía un color inválido, la sección de etiquetas del tablero dejaba de funcionar para todos sus miembros.

HackerOne lo clasifica como error de lógica de negocio, con severidad baja. Hubo recompensa, pero el importe no es público.

Pasos de reproducción

  1. Entra con un usuario normal que tenga acceso a un tablero de Deck. No hacen falta permisos especiales.
  2. Crea una etiqueta desde la interfaz e intercepta la petición que se envía.
  3. Cambia el valor de color por una cadena que no sea un color, por ejemplo anything, y reenvía la petición:
POST /apps/deck/labels HTTP/1.1
Host: 127.0.0.1:8080
requesttoken: <token>
Cookie: <session>

{
  "cardId": null,
  "color": "anything",
  "title": "khoof",
  "boardId": 2
}
  1. El servidor responde sin errores:
HTTP/1.1 200 OK
  1. Abre el tablero: las etiquetas ya no se muestran y la pantalla de gestión de etiquetas no se abre.

Impacto

  • Las etiquetas del tablero dejan de mostrarse y nadie puede verlas, editarlas ni gestionarlas.
  • Afecta a todos los usuarios del tablero, no solo a quien crea la etiqueta.
  • El daño persiste: el valor inválido queda en la base de datos y, según el investigador, solo se arregla limpiándolo a mano en el backend.
  • Basta con el acceso normal de cualquier miembro del tablero.

El impacto se queda en una denegación de servicio de esa función del tablero y en datos corruptos en sus metadatos. El reporte no describe ninguna ejecución de código ni fuga de datos.

Remediación

El investigador propuso que el servidor validase color de forma estricta, aceptando solo los colores predefinidos o formatos HEX/RGB válidos, y que devolviese un error 4xx con cualquier otro valor. El reporte consta como resuelto, pero no detalla cómo se corrigió.

Qué aprender de este caso

  • En apps de tableros, calendarios o etiquetas, prueba los campos que la interfaz solo deja elegir de una paleta o un selector, como color, icon o theme. Muchas veces el servidor da por hecho que la interfaz ya limita el valor y no lo comprueba.
  • Cuando un dato lo guarda un usuario y lo ven todos, un valor que rompe el renderizado afecta a todo el grupo. Busca ese efecto en recursos compartidos, no solo en tu propia vista.
  • Si un campo tiene un formato fijo, compruébalo en el servidor antes de guardar, por ejemplo con una lista de colores permitidos o una expresión como ^#[0-9a-fA-F]{6}$, y responde con un 400 si no encaja.
  • En el frontend, si llega un color inesperado, usa uno por defecto en lugar de dejar de mostrar la lista. Así un solo registro corrupto no tumba toda la sección.