Files
karibeo_backend_admin/SECURITY.md
2025-10-12 00:50:51 +00:00

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:

  1. Abrir DevTools en el navegador
  2. Modificar localStorage.setItem('karibeo-user', JSON.stringify({...user, role: 'admin'}))
  3. Obtener acceso completo al panel de administración

SOLUCIÓN REQUERIDA PARA PRODUCCIÓN:

Opción A: Backend con verificación de roles (RECOMENDADO)

  1. Crear tabla user_roles en la base de datos (separada de users/profiles)
  2. Implementar verificación de roles en el backend
  3. Cada endpoint de API debe verificar permisos en el servidor
  4. 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:

  1. Aceptar el riesgo - La verificación del cliente es solo para UX
  2. No almacenar datos sensibles - Nada crítico debe depender de roles
  3. Implementar ofuscación - Dificultar (no prevenir) manipulación
  4. 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.ts con 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

  1. 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
  2. Documentación de Seguridad

    • Este documento SECURITY.md
    • Comentarios de advertencia en código crítico
    • Guías de implementación segura
  3. 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