Refactor: Analyze and fix security issues
This commit is contained in:
gpt-engineer-app[bot]
202
SECURITY.md
Normal file
202
SECURITY.md
Normal file
@@ -0,0 +1,202 @@
|
||||
# 🔒 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**:
|
||||
```typescript
|
||||
// ❌ 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
|
||||
|
||||
```sql
|
||||
-- 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`
|
||||
|
||||
```typescript
|
||||
// ⚠️ 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**:
|
||||
```typescript
|
||||
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
|
||||
|
||||
- [OWASP Top 10](https://owasp.org/www-project-top-ten/)
|
||||
- [Supabase Security Best Practices](https://supabase.com/docs/guides/auth/row-level-security)
|
||||
- [JWT Security Best Practices](https://tools.ietf.org/html/rfc8725)
|
||||
- [Input Validation with Zod](https://zod.dev/)
|
||||
|
||||
## 📞 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
|
||||
Reference in New Issue
Block a user