Musify/docs/presigned-upload-hardening.md

Hardening: abuso de pre-signed uploads (Opción B)

Contexto

Con la Opción B el backend genera URLs pre-firmadas (pre-signed) para que el cliente suba ficheros directamente a S3, y luego el backend crea/actualiza entidades en DB referenciando pictureName/audioName.

Esto mejora latencia y descarga el host/servicio, pero abre un vector de abuso: un usuario puede llamar muchas veces a RequestPlayListPictureUpload / RequestTrackUploadUrls y subir muchos objetos a S3 sin llegar a crear la entidad final (objetos “huérfanos”).

Qué pasa hoy si el usuario spamea

• Se generan muchas URLs pre-firmadas (costo bajo pero no cero).
• El usuario puede subir muchos objetos a S3 sin relación con una entidad en DB.
• El impacto principal es:
  • coste/uso de S3 (storage + requests)
  • posible saturación del componente de generación de URLs

Objetivo

Reducir abuso y coste, manteniendo:

• UX simple
• backend sin streams
• workflows asíncronos + MassTransit Outbox

Qué significa “sólido” aquí

Como el upload es directo a S3 (o compatible), el backend no puede garantizar “single-use” del upload en el lado del storage mientras una URL sea válida. Por tanto, el objetivo realista es:

• Asegurar que cualquier abuso solo pueda impactar un prefijo temporal barato de limpiar.
• Poner límites duros (cuotas) en DB para que el coste tenga un techo.
• No aceptar referencias a objetos no válidos (verificación antes de consumir).
• Evitar pérdida de datos en reemplazos (no borrar la versión previa hasta éxito).

Principio de configuración (no hardcode)

Todas las rutas/prefijos/TTLs/límites deben ser configurables.

Regla:

• En Application/Infrastructure no debe haber strings hardcodeadas de keys S3 (p.ej. temp/, uploads/, PlayLists/, Tracks/).
• Las rutas deben centralizarse en opciones/config (p.ej. StorageRoutes, PlayListRoutes, TrackRoutes, o similar), de forma que cambiar la convención de keys no requiera tocar lógica.

Los ejemplos de este documento son convenciones sugeridas y deben leerse como plantillas parametrizadas.

Invariantes de seguridad (reglas que no se rompen)

• El cliente solo puede escribir en rutas temporales bajo {TempRootPrefix}/... (o el prefijo temporal equivalente). La ruta final nunca recibe credenciales pre-firmadas.
• Cada intent emite un Key nuevo (GUID). No hay keys “estables” para reusar.
• Una entidad solo apunta a un pictureName/audioName si su intent asociado se valida y se consume.
• Reemplazos: el borrado de la versión anterior ocurre al final del workflow, tras actualizar DB.

Prioridad (coste alto)

Si el coste es el principal riesgo, el orden recomendado es:

1. Cuotas duras en DB (intents activos + bytes activos) + job de expiración.
2. Prefijo temporal + cleanup por prefijo (lifecycle si existe, y job como fallback).
3. Validación de objeto (HEAD) antes de consumir.
4. (Opcional) Migrar a pre-signed POST si el backend de storage lo soporta bien.

Decisiones validadas (no tocaría)

• El orden de prioridad (cuotas → prefijo temporal → HEAD → POST) es el más sensato cuando el coste es el riesgo principal.
• La advertencia sobre S3-compatible / SeaweedFS es importante: el diseño debe ser seguro sin depender de features avanzadas.
• El principio de no hardcodear rutas y centralizar prefijos/convenciones en config es coherente con el estilo del repo.
• La semántica de errores debe permanecer separada del mapeo a códigos/respuestas (responsabilidad del host/presentación).
• En reemplazos, no borrar la versión anterior hasta éxito del workflow es clave para resiliencia con Courier.

Mitigaciones recomendadas (pueden coexistir)

1) “Upload intents” en DB (control y conciliación)

Persistir una intención de upload cuando se genera un pre-signed URL.

Importante: no usar el nombre original del fichero como pictureName/audioName. La key debe usar un identificador generado (p.ej. GUID) para evitar colisiones, inputs “raros” y facilitar cleanup.

Sugerencia práctica:

• objectName = {guid}.{ext} (o directamente {guid} si la extensión no aporta valor)
• Guardar originalFileName solo como metadata opcional (si se necesita para UI), pero nunca como key.

Modelo sugerido (mínimo):

• UploadIntent
  • Id
  • UserId
  • Bucket
  • Key
  • ContentType
  • ExpectedSizeBytes (opcional; si el caller conoce el tamaño)
  • ExpiresAt
  • Status: Issued | Consumed | Expired
  • CreatedAt

Opcional (útil para auditoría/UX):

• OriginalFileName
• Purpose (TrackPicture | TrackAudio | PlayListPicture)

Reglas:

• Al pedir URL (RequestUpload):
  • insertar intent Issued
  • imponer límites por usuario (ver “Cuotas”)
  • si supera el límite: fallar con un error semántico (p.ej. UploadIntentLimitExceeded)
• Al crear/actualizar entidad (Create*/Update* V2):
  • validar que el pictureName/audioName recibido corresponde a un intent Issued del mismo UserId y no expirado
  • validar que el objeto existe en S3 (HEAD) y que tamaño / Content-Type cumplen la policy del backend
  • marcar intent como Consumed

Cuotas (anti-cost) 🔴 Alta

Además del conteo de intents, imponer cuotas por bytes para que el coste tenga techo.

Recomendación mínima:

• MaxActiveUploadIntentsPerUser (número)
• MaxActiveUploadBytesPerUser (bytes) — suma de objetos temporales “en vuelo” por usuario

Cómo aproximarlo sin streams:

• Guardar ExpectedSizeBytes en el intent (si está disponible).
• Si no se dispone del tamaño, usar un valor conservador por Purpose (p.ej. imagen <= X, audio <= Y) y validarlo en HEAD antes de consumir.

Nota: si el caller puede mentir sobre tamaño, no confíes ciegamente en ExpectedSizeBytes; úsalo como guardrail y valida al consumir.

Semántica de errores (intent inválido) 🟡 Media

Definir errores semánticos y dejar el mapeo al “caller” (host/presentación):

• UploadIntentLimitExceeded
• UploadIntentNotFoundOrNotAccessible (si se quiere no filtrar existencia)
• UploadIntentAlreadyConsumed
• UploadIntentExpired
• UploadObjectNotFound
• UploadObjectPolicyViolation (tamaño, Content-Type, extensión, etc.)

Nota sobre race conditions en el límite 🟡 Media

El check “count(Issued) < Max” es vulnerable a concurrencia (dos requests paralelas pueden pasar el check y crear 2 intents extra).

Mitigaciones (de menor a mayor robustez):

• Ejecutar check + insert en la misma transacción con aislamiento fuerte (p.ej. SERIALIZABLE).
• Usar un mecanismo de lock por usuario (p.ej. advisory lock en PostgreSQL) durante la emisión.
• Modelar el límite con una tabla/contador por usuario y aplicar update condicional (estilo “compare-and-swap”).

Job de expiración de intents 🔴 Alta

Aunque ExpiresAt esté en DB, hace falta un mecanismo que marque y limpie intents caducados:

• Un job periódico (worker/cron) que:
  • marque intents Issued con ExpiresAt < now como Expired
  • opcionalmente encole el borrado del objeto S3 (si existe)

Si se aplica lifecycle en S3 (ver sección 2), el job puede ser “solo DB” (marcar Expired) y dejar el borrado real a S3.

Adicionalmente, este job es un buen sitio para:

• borrar intents Expired antiguos (retención de auditoría configurable)
• emitir métricas/contadores (intents expirados por usuario)

Ventajas:

• Previene spam con reglas duras y auditables.
• Permite cleanup de huérfanos con certeza.

Coste:

• entidad + migración + lógica de validación.

2) Limitar el scope del pre-signed URL (reducción de daño)

Aplicar restricciones conservadoras:

• Reducir TTL:
  • ExpiresInSeconds más bajo (p.ej. 60–120s en vez de 600s)
• Validar/limitar:
  • ContentType permitido
  • extensiones permitidas (FileType)
• Usar keys temporales por usuario:
  • Opción recomendada (facilita lifecycle por prefijo):
    • {TempRootPrefix}/{userId}/playlists/{guid}.{ext}
    • {TempRootPrefix}/{userId}/tracks/{guid}.{ext}
  • Alternativa (si se quiere mantener todo bajo uploads/{userId}):
    • {UploadsRootPrefix}/{userId}/PlayLists/TempUploads/{guid}.{ext}
    • {UploadsRootPrefix}/{userId}/Tracks/TempUploads/{guid}.{ext}

Luego, en el workflow/worker:

• mover/copiar desde la ruta temporal (p.ej. temp/... o .../TempUploads/...) a la ruta final (OriginalPictures/... / OriginalAudios/...)
• borrar el objeto temporal

Ventajas:

• Cleanup masivo sencillo (por prefijo {TempRootPrefix}/)
• Reduce el impacto de huérfanos.

S3 Lifecycle Rule en TempUploads 🔴 Alta

Configurar una Lifecycle Rule en el bucket para auto-expirar objetos bajo el prefijo de temporales, por ejemplo:

• Prefijo: {TempRootPrefix}/
• Expiración: 1–7 días (según tolerancia a reintentos)

Nota: las reglas de lifecycle por prefijo no soportan comodines en medio (p.ej. uploads/*/...). Si se usa la alternativa uploads/{userId}/.../TempUploads/..., para filtrar correctamente se recomienda:

• cambiar la convención de key para que el prefijo sea común (p.ej. {TempRootPrefix}/...), o
• usar tags en los objetos (p.ej. temporary=true) y filtrar la lifecycle rule por tag (si se puede firmar el tagging en el upload).

Esto evita que el coste de huérfanos crezca indefinidamente incluso si el job de cleanup falla.

Cleanup backend (fallback) 🔴 Alta

No dependas solo de lifecycle del storage (en S3 compatibles puede variar). Añadir un job de cleanup que:

• liste por prefijo temporal {TempRootPrefix}/
• borre objetos con edad > TempUploadsRetentionDays

Este job debe ser:

• incremental (paginación)
• tolerante a errores (reintentos)
• con límites de throughput (para no auto-generar costes por borrar en masa)

Restricción de Content-Type en S3 🟡 Media

Si el objetivo es enforcement “duro” a nivel de S3 (no solo validación posterior), pre-signed POST suele ser más robusto que PUT.

pre-signed PUT (lo actual en este repo):

• Permite fijar Content-Type si se pre-firma incluyendo ese header.
• Es más limitado para imponer condiciones ricas (tamaño, tags, etc.).
• Recomendación: combinar con validación posterior (HEAD) antes de consumir el intent.

pre-signed POST (recomendado si buscas más control):

• Permite policy conditions como:
  • content-length-range (tamaño máximo)
  • eq/starts-with para Content-Type
  • key/prefijo (el cliente no elige keys fuera del scope)
  • headers requeridos (p.ej. SSE)
  • opcional: tagging (p.ej. temporary=true) para lifecycle por tag

Trade-off: el cliente sube con multipart/form-data (POST), pero el backend sigue sin manejar streams.

Nota S3-compatible / SeaweedFS 🟡 Media

No todos los backends S3 compatibles implementan al 100%:

• policy conditions de POST
• tagging en upload
• respuestas/errores idénticos a AWS

Recomendación:

• Diseñar el sistema para ser seguro sin depender de condiciones avanzadas (keys únicas + prefijo temporal + cuotas + verificación HEAD).
• Tratar POST/condiciones como una mejora opcional, tras validar compatibilidad del backend.

Reemplazos: no borrar originales antiguos hasta éxito ✅

Al actualizar una imagen/audio existente:

• Subir el nuevo binario a la ruta temporal (p.ej. {TempRootPrefix}/.../{newGuid}).
• Procesar (resize/transcode) y subir a rutas finales con nombres nuevos.
• Actualizar la entidad en DB para apuntar a los nuevos *PictureName/*AudioFolderName.
• Solo al final borrar los objetos antiguos (original + sizes / audio procesado), cuando el workflow haya completado.

Esto evita perder la versión anterior si el worker falla a mitad (punto crítico para resiliencia).

Validación del objeto antes de consumir (HEAD) 🔴 Alta

Antes de consumir un intent y actualizar DB:

• HEAD Bucket/Key
• validar Content-Type esperado (según Purpose)
• validar tamaño máximo (MaxUploadBytes o por propósito)
• (opcional) validar extensión inferida de Key si se usa

Si falla la validación:

• no consumir el intent
• marcarlo como violación o dejarlo expirar
• el cleanup se encarga del objeto

Orden de implementación sugerido

1. Upload intents en DB (límite de activos + validación al crear/actualizar)
2. Reducir TTL y mover a rutas temporales + S3 lifecycle + cleanup
3. Si se requiere enforcement fuerte: migrar a pre-signed POST + policy conditions

Parámetros recomendados (config)

• UploadUrlExpiresInSeconds (default: 120)
• MaxActiveUploadIntentsPerUser (default: 5)
• MaxActiveUploadBytesPerUser (default sugerido: depende de coste; p.ej. 200MB)
• AllowedPictureExtensions / AllowedAudioExtensions
• AllowedContentTypes (lista blanca)
• TempUploadsRetentionDays (default: 3)
• PresignedUploadMethod (default sugerido: POST si se quiere enforcement fuerte; PUT si se prioriza simplicidad)
• MaxUploadBytes (límite máximo de tamaño por upload)

Jobs (config):

• UploadIntentsExpirationJobIntervalSeconds
• TempUploadsCleanupJobIntervalSeconds
• ExpiredIntentsRetentionDays

Rutas/prefijos (ejemplos):

• TempRootPrefix (default sugerido: temp)
• UploadsRootPrefix (default sugerido: uploads)

Notas

• Estas defensas complementan el Outbox: el Outbox garantiza entrega de eventos tras commit, pero no evita el abuso de generación de URLs o almacenamiento de objetos huérfanos.