6.6 KiB
🔒 Reporte de Seguridad del Proyecto Karibeo
⚠️ ADVERTENCIAS CRÍTICAS DE SEGURIDAD
1. CRÍTICO: Verificación de Roles del Cliente (NO SEGURO PARA PRODUCCIÓN)
PROBLEMA: El sistema actual verifica roles de administrador usando el objeto user almacenado en localStorage del cliente.
Archivos afectados:
src/hooks/useAdminData.ts(línea 18)src/hooks/useEmergencyData.ts(línea 16)src/App.tsx(línea 131)src/pages/SignIn.tsx(línea 33)
Por qué es inseguro:
// ❌ INSEGURO - Un atacante puede modificar localStorage
const isAdmin = user?.role === 'admin';
Un atacante puede:
- Abrir DevTools en el navegador
- Modificar
localStorage.setItem('karibeo-user', JSON.stringify({...user, role: 'admin'})) - Obtener acceso completo al panel de administración
SOLUCIÓN REQUERIDA PARA PRODUCCIÓN:
Opción A: Backend con verificación de roles (RECOMENDADO)
- Crear tabla
user_rolesen la base de datos (separada deusers/profiles) - Implementar verificación de roles en el backend
- Cada endpoint de API debe verificar permisos en el servidor
- Usar Row Level Security (RLS) en Supabase
-- Ejemplo de estructura segura
CREATE TABLE user_roles (
id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
user_id UUID REFERENCES auth.users(id) ON DELETE CASCADE,
role TEXT NOT NULL CHECK (role IN ('admin', 'super_admin', 'user', 'hotel', 'restaurant')),
created_at TIMESTAMPTZ DEFAULT NOW(),
UNIQUE(user_id, role)
);
-- Función de seguridad definer (evita recursión RLS)
CREATE OR REPLACE FUNCTION has_role(_user_id UUID, _role TEXT)
RETURNS BOOLEAN
LANGUAGE SQL
STABLE
SECURITY DEFINER
SET search_path = public
AS $$
SELECT EXISTS (
SELECT 1 FROM user_roles
WHERE user_id = _user_id AND role = _role
)
$$;
-- Política RLS usando la función
CREATE POLICY "Only admins can view all data"
ON some_table
FOR SELECT
TO authenticated
USING (has_role(auth.uid(), 'admin'));
Opción B: Sin Backend
Si NO puedes implementar backend:
- Aceptar el riesgo - La verificación del cliente es solo para UX
- No almacenar datos sensibles - Nada crítico debe depender de roles
- Implementar ofuscación - Dificultar (no prevenir) manipulación
- Rate limiting - Limitar llamadas a API
2. Validación de Inputs Insuficiente
PROBLEMA: La mayoría de formularios no tienen validación robusta.
Archivos sin validación:
- ✅
src/pages/SignIn.tsx- CORREGIDO - ✅
src/pages/SignUp.tsx- CORREGIDO - ❌
src/pages/dashboard/AddListing.tsx - ❌
src/pages/dashboard/Settings.tsx - ❌
src/pages/dashboard/Profile.tsx
Riesgos:
- Inyección SQL (si el backend no valida)
- XSS (Cross-Site Scripting)
- Datos corruptos en la base de datos
- Buffer overflow en campos de texto
SOLUCIÓN IMPLEMENTADA:
- Creado
src/lib/validation.tscon schemas de validación usando zod - Actualizado SignIn.tsx con validación completa
- Actualizado SignUp.tsx con validación robusta
3. Credenciales Mock Hardcoded
PROBLEMA: Usuarios de prueba con contraseñas conocidas en src/contexts/AuthContext.tsx
// ⚠️ DESARROLLO SOLAMENTE
const mockUsers = {
'superadmin@karibeo.com': { password: '123456', role: 'super_admin' },
'admin@karibeo.com': { password: '123456', role: 'admin' },
'user@karibeo.com': { password: '123456', role: 'tourist' }
};
SOLUCIÓN:
- ✅ Agregada documentación clara de que es solo para desarrollo
- ⚠️ CRÍTICO: Eliminar estos usuarios antes de producción
- ⚠️ CRÍTICO: Usar variables de entorno para credenciales de prueba
4. Tokens en localStorage
PROBLEMA: Tokens JWT almacenados en localStorage son vulnerables a XSS.
Estado actual:
localStorage.setItem('karibeo-token', token);
Riesgo: Si hay una vulnerabilidad XSS, un atacante puede robar tokens.
SOLUCIÓN (para implementar):
- Usar HttpOnly cookies (requiere backend)
- Implementar refresh tokens con rotación
- Tokens de corta duración (15 minutos)
- Refresh tokens en HttpOnly cookies
5. Sin Rate Limiting
PROBLEMA: No hay protección contra ataques de fuerza bruta en login.
SOLUCIÓN REQUERIDA:
- Implementar rate limiting en el backend
- Bloquear IPs después de N intentos fallidos
- Captcha después de 3 intentos
- Retrasos progresivos entre intentos
✅ Mejoras Implementadas
-
Validación de Inputs con Zod
- Schemas de validación centralizados en
src/lib/validation.ts - Validación de email, password, nombres, teléfonos
- Mensajes de error descriptivos
- Protección contra caracteres maliciosos
- Schemas de validación centralizados en
-
Documentación de Seguridad
- Este documento SECURITY.md
- Comentarios de advertencia en código crítico
- Guías de implementación segura
-
Mejora de Formularios de Autenticación
- SignIn con validación completa
- SignUp con validación de password seguro
- Manejo de errores mejorado
📋 Checklist de Seguridad para Producción
ANTES DE DEPLOY:
- Eliminar usuarios mock de AuthContext.tsx
- Implementar verificación de roles en el backend
- Crear tabla user_roles separada
- Implementar RLS policies en Supabase
- Migrar tokens a HttpOnly cookies
- Implementar rate limiting
- Auditar todos los endpoints de API
- Habilitar CORS solo para dominios conocidos
- Configurar CSP (Content Security Policy)
- Implementar logging de intentos de acceso no autorizado
- Agregar validación en TODOS los formularios
- Sanitizar HTML en campos de texto rico
- Configurar HTTPS obligatorio
- Implementar 2FA para administradores
- Revisar dependencias con
npm audit - Configurar variables de entorno adecuadamente
- Implementar monitoreo de seguridad
TESTING DE SEGURIDAD:
- Pruebas de penetración
- Análisis de vulnerabilidades XSS
- Análisis de inyección SQL
- Pruebas de escalación de privilegios
- Pruebas de autenticación bypass
- Pruebas de CSRF
🔗 Recursos Adicionales
📞 Contacto de Seguridad
Si descubres una vulnerabilidad de seguridad, por favor NO la publiques públicamente. Contacta al equipo de desarrollo directamente.
Última actualización: ${new Date().toISOString().split('T')[0]} Versión del documento: 1.0 Estado: Desarrollo - NO apto para producción sin correcciones