🚨 Reporte de Incidentes YASTA

📅 25 de Julio, 2025
📱 INCIDENTE #3: Check-ins Automáticos No Autorizados

⚠️ ¿Qué pasó?

🎭 Evento Afectado:

"Isabel Fernández (4:00 pm)" - Programado para el 02 de agosto

Se registraron check-ins automáticos cuando estos no deberían realizarse hasta la fecha del evento.

🎫 Check-ins Prematuros
Se activaron automáticamente antes del evento
🔍 Investigación
Solo afectó a UN evento específico
🕵️ Evidencia Clave
Otros eventos programados en YASTA no fueron afectados

🔍 Análisis del Caso:

<>CASO AISLADO: De todos los eventos realizados o programados en YASTA solo el evento de Isabel Fernández (4:00 pm) tuvo este problema. Los otros eventos no tuvieron alguna afectación. EL equipo de soporte hizo pruebas de reproducción de la vulnerabilidad, sin embargo no pudieron replicar el mismo error. Y al no poder replicar los check in, una opcion es que se opta por cambiar contraseñas de los usuarios de STAFF y ADMIN que tienen acceso a la funcionalidad de check-in como medida preventiva de que pudiera ser una persona. Sin embargo se seguira analizando mas a profundidad esa funcionalidad en especifico, buscando una vulnerabilidad o funcion defectuosa.

🔒 Medidas preventivas

🔐 Cambio de Credenciales
Renovación inmediata de contraseñas y accesos
🛡️ Protocolos de Seguridad
Fortalecimiento de medidas preventivas
👁️ Monitoreo Continuo
Vigilancia activa para prevenir futuros casos

🔍 Explicación Simple:

Al ir ligadas las acciones de check in con un token de autenticación, es necesario cambiar la contraseñas de los usuarios que tienen acceso a esta funcionalidad en este caso STAFF y ADMIN. Es como si alguien con llaves de la casa entrara y moviera cosas específicas - no es un problema de la cerradura, sino del manejo de las llaves.

🗺️ INCIDENTE #2: Mapas de Eventos No Visibles

⚠️ ¿Qué pasó?

🔍 Explicación Simple:

Los mapas de asientos se guardan normalmente en AWS S3 (como un disco duro en internet). Cuando esto falló, se guardaron en el servidor local, pero el sistema no sabía cómo encontrarlos.

☁️ Falla AWS S3
No se podían guardar mapas en la nube
💾 Respaldo Local
Se guardaron en carpetas del servidor
🚫 Router Confundido
No reconocía las nuevas ubicaciones

🛠️ ¿Cómo se solucionó?

🔧 Solución Inmediata
Se modificó el router para encontrar mapas locales
🔍 Investigación
Se está arreglando la conexión con AWS

🔍 Explicación Simple:

Es como cuando cambias los archivos de lugar en tu computadora. Tuvimos que "enseñarle" al sistema dónde encontrar los mapas en su nueva ubicación temporal.

🎫 INCIDENTE #1: Eventos Marcados Como "SOLD OUT" Incorrectamente

⚠️ ¿Qué pasó?

😈 Usuarios Maliciosos
Apartaban todos los boletos disponibles
⏰ 10 Minutos
Mantenían boletos "reservados" sin comprar
🚫 SOLD OUT Falso
Los eventos aparecían agotados artificialmente

🔍 Explicación Simple:

Imagina que en un cine, alguien puede "apartar" todos los asientos por 10 minutos sin pagar. Si varias personas hacen esto repetidamente, el cine aparece como "lleno" aunque nadie haya comprado boletos realmente.

¿Cómo se solucionó?

💳 Pago Primero
Los boletos solo se descuentan después del pago exitoso
🔄 Verificación en Tiempo Real
Se verifica disponibilidad antes del pago
📱 Notificación Inmediata
Aviso si los boletos ya no están disponibles
🔒

Incidente #3

RESUELTO Y ASEGURADO

Check-ins corregidos, credenciales renovadas

⚠️

Incidente #2

SOLUCIONADO TEMPORALMENTE

Los mapas son visibles, trabajando en solución definitiva

Incidente #1

COMPLETAMENTE RESUELTO

Los eventos ya no se marcan como "SOLD OUT" incorrectamente

🛡️ Acciones Preventivas

Se implementarán sistemas de monitoreo avanzados para detectar problemas antes de que afecten a los usuarios

Detección de patrones anómalos (como el abuso de reservas)

Alertas tempranas para problemas de conectividad con servicios externos

Monitoreo continuo Monitoreo de accesos para detectar manipulaciones, asi como analisis mas exaustivos de funciones detonantes de check-in

Auditorias programadas Auditoría de credenciales con renovación automática