Este documento define la estructura de gobierno de ciberseguridad, monitoreo, auditoría y asignación de responsabilidades para mantener la confidencialidad, integridad y disponibilidad del ecosistema FlorApp (Android + Django REST Framework).

---

Las políticas definidas en el Sprint 1 se actualizan formalmente en función de las implementaciones técnicas reales efectuadas por el equipo.

ID Política	Política de Seguridad	Frecuencia de Revisión	Responsable(s)	Mecanismo de Control / Auditoría
POL-SEC-01	Gestión de Credenciales: Prohibido el hardcodeo de claves o SECRET_KEY. Manejo vía variables de entorno (.env).	En cada Pull Request	Eric Heredia / Kiara Fernandez	Revisión de código (Code Review) antes de mergear a develop. (Casos asociados: TC-SEC-04)
POL-SEC-02	Autenticación Fuerte via JWT: Expiración de Access Tokens y Refresh Tokens. Almacenamiento seguro en SharedPreferences privado.	Por Sprint	Carlos Balbastro / Darío Bosque	Auditoría de peticiones HTTP con tokens vencidos o manipulados. (Casos asociados: TC-LOG-01, TC-LOG-02, TC-SEC-04, TC-SEC-05, TC-SEC-06, TC-SEC-07)
POL-SEC-03	Políticas Globas de Permisos y Endpoints: Denegación por defecto (IsAuthenticated global en DRF), permitiendo canales públicos controlados (AllowAny) solo para login, registro y la galería general de flora.	Por Release	Ignacio Bentivoglio / Florencia Lorenzati	Validación de accesos públicos/privados. (Casos asociados: TC-SEC-PUB-01, TC-SEC-PUB-02, TC-SEC-ROL-01, TC-SEC-ROL-02)
POL-SEC-04	Protección de Datos y Anti-IDOR: Validación de propiedad sobre los recursos. Un usuario no puede modificar recursos de terceros.	Por Sprint	Florencia Lorenzati	Verificación de permisos por ID de objeto mediante pruebas con Postman. (Casos asociados: TC-SEC-01, TC-SEC-02)
POL-SEC-05	Almacenamiento Seguro de Claves: Hash nativo de Django (PBKDF2). Prohibido guardar contraseñas en texto plano.	Por Release	Dario Bosque	Verificación de hashes en tablas de MySQL y validación de métodos check_password. (Casos asociados: TC-LOG-02)
POL-SEC-06	Registros de Auditoría: Monitoreo de intentos de acceso denegado (401/403) y fallos de autenticación en los logs de la API.	Semanal o antes de cada entrega	Eric Heredia	Inspección de logs de la aplicación en consola o archivo sin exponer credenciales. (Casos asociados: TC-LOG-02, TC-SEC-05)

---

• Ingreso y Registro de Usuario: Formulario visible para acceder a la cuenta.
• Cierre de Sesión: Botón para salir de la aplicación.
• Modo Invitado: Opción para explorar el catálogo sin autenticarse inmediatamente.

• Limpieza de Tokens al Cerrar Sesión: La app elimina las credenciales locales de SharedPreferences al presionar "Cerrar Sesión" para prevenir accesos no autorizados en el dispositivo local.
• Hash No Reversible de Claves: El sistema aplica check_password de Django de forma transparente para que las contraseñas permanezcan cifradas e ilegibles incluso en la base de datos MySQL.
• Control Global de Permisos (Anti-IDOR): El backend valida en cada petición HTTP que el usuario autenticado sea el dueño del recurso antes de devolver o modificar información.

---

Las medidas de seguridad implementadas protegen directamente los requerimientos funcionales del sistema bajo estándares profesionales:

• Requerimiento (Gestión y Edición de Fichas de Plantas / REQNF-05): Protegido mediante la política POL-SEC-04 (Anti-IDOR) y validado mediante los casos de prueba TC-SEC-01 y TC-SEC-02.
  • Implementación real: El backend valida mediante el método auxiliar _obtener_especie_permitida que el ID del usuario autenticado corresponda al dueño legítimo del recurso antes de entregar datos o permitir modificaciones, respondiendo con un 403 Forbidden ante vulnerabilidades de manipulación de URLs. (Para mayor detalle técnico, ver el informe completo de Blindaje de Endpoints, Autenticación JWT y Control de Acceso IDOR).
• Requerimiento (Configuración y Despliegue del Servidor): Protegido mediante la política POL-SEC-01 (Gestión de Secretos) y validado con el caso de prueba TC-SEC-04.
  • Implementación real: Lectura de configuraciones críticas mediante os.getenv() en settings.py para evitar la exposición de credenciales en el código fuente del repositorio.

---

1. Protocolo y Librería: Se implementó djangorestframework-simplejwt sobre Django REST Framework mediante un serializador personalizado (CustomTokenObtainPairSerializer) para procesar credenciales por correo electrónico (email) y contraseña contra el modelo de usuario propio, acompañado de una clase de autenticación adaptada (CustomJWTAuthentication) para decodificar con seguridad el user_id.
2. Ciclo de Vida del Token:
   • El cliente (Android) envía credenciales (email y password) al endpoint /api/token/.
   • El backend valida la clave mediante hashes PBKDF2 y responde el par de tokens: Access Token (corta duración con cabecera Authorization: Bearer <token>) y Refresh Token.
3. Persistencia en el Cliente Mobile: El Access Token se almacena en SharedPreferences en modo privado (MODE_PRIVATE), restringiendo el acceso únicamente al paquete de la app (com.ispc.florappmovil).
4. Mitigación de Vulnerabilidades IDOR: Se incorporó el método auxiliar _obtener_especie_permitida en el backend para validar de forma estricta la autoría de las fichas de flora, complementado con la protección de rutas perimetrales en Angular mediante Route Guards (auth.guard.ts) y parámetros de control (es_edicion=true).

(Nota complementaria: Para la validación estricta y blindaje contra la escalada de privilegios en los serializers de usuarios, consultar el informe específico de Prevención de Escalada de Privilegios y Blindaje de Serializers de Usuarios).

---

• Se implementó un control de acceso estricto basado en roles (Administrador vs. Docente).
• Se comprobó mediante pruebas cruzadas que un usuario con rol docente no puede consultar fichas privadas ajenas ni ejecutar funciones administrativas. Los intentos de acceso no autorizado se bloquean de inmediato en la API con el código 403 Forbidden, previniendo la reasignación indebida de propiedad.

---

• La aplicación móvil nativa en Android se comunica con el backend enviando de forma dinámica el token de acceso en las cabeceras de cada petición HTTP protegida (Authorization: Bearer <token> mediante Retrofit).
• Las credenciales locales se conservan de forma cifrada/privada en el dispositivo mediante SharedPreferences (MODE_PRIVATE), garantizando que al cerrar sesión se limpien los registros locales.

---

Conforme a la matriz oficial de QA del proyecto (QA Test Cases), se planificaron, diseñaron y ejecutaron los siguientes casos de prueba en materia de ciberseguridad:

• TC-SEC-01 (Validación de bloqueo contra modificación IDOR - Método PUT / BUG-SEC-01) Pull Request #94:

  • Política relacionada: POL-SEC-04.
  • Descripción: Comprueba que al intentar modificar registros o la propiedad de plantas de otros usuarios cambiando el ID en solicitudes PUT, el sistema bloquee la acción.
  • Diseñado por: M. Florencia Lorenzati.
  • Ejecutado por: Ignacio Bentivoglio y M. Florencia Lorenzati.
  • Resultado: Bug inicial: permitía modificar fichas ajenas y reasignar propiedad cambiando el ID en la URL. Fix (PR #94): validación estricta en backend con _obtener_especie_permitida (retorna 403 Forbidden) y manejo de errores en frontend. Re-ejecutado con éxito.
  • Estado Final: Pass.

• TC-SEC-02 (Validación de bloqueo contra lectura IDOR en URL - Método GET / BUG-SEC-02) Pull Request #94:

  • Política relacionada: POL-SEC-04.
  • Descripción: Comprueba que al cambiar el parámetro numérico en la barra de direcciones para acceder a fichas privadas de otros usuarios, el sistema bloquee la visualización y retorne acceso denegado.
  • Diseñado por: Ignacio Bentivoglio.
  • Ejecutado por: M. Florencia Lorenzati.
  • Resultado: Bug inicial: permitía visualizar datos confidenciales de fichas ajenas alterando el ID en la URL. Fix (PR #94): protección con auth.guard.ts, parámetro es_edicion=true en servicio y limpieza de interfaz con this.form.reset(). Re-ejecutado con éxito.
  • Estado Final: Pass.

• TC-SEC-PUB-01 (Verificación de denegación de acceso anónimo en endpoints protegidos):

  • Política relacionada: POL-SEC-03.
  • Descripción: Comprueba que el backend de Django rechaza de inmediato cualquier intento de modificación (POST, PUT, DELETE) o acceso a rutas privadas sin token JWT, respondiendo con un código de estado 401 Unauthorized.
  • Diseñado por: M. Florencia Lorenzati.
  • Ejecutado por: Ignacio Bentivoglio.
  • Resultado: PASSED (El sistema reconoce que no hay Token de acceso, por lo que bloquea la petición y devuelve el código de estado 401 Unauthorized).

• TC-SEC-PUB-02 (Verificación de disponibilidad en endpoints públicos esenciales):

  • Política relacionada: POL-SEC-03.
  • Descripción: Comprueba que los recursos indispensables (como la galería de flora, el inicio de sesión y el registro) permanezcan abiertos para usuarios anónimos o visitantes.
  • Diseñado por: M. Florencia Lorenzati.
  • Ejecutado por: Ignacio Bentivoglio.
  • Resultado: PASSED (El sistema permite el acceso de manera fluida respondiendo con código HTTP 200 OK y mostrando la información correspondiente).

• TC-SEC-ROL-01 (Prevención de Escalada de Privilegios mediante PUT en Serializers de Usuarios):

  • Política relacionada: POL-SEC-03 / POL-SEC-04.
  • Descripción: Verificar que un usuario con rol no administrador (Docente) no pueda elevar sus privilegios a Administrador alterando el JSON del campo rol en petición PUT hacia la API de usuarios.
  • Diseñado por: Ignacio Bentivoglio.
  • Ejecutado por: M. Florencia Lorenzati.
  • Resultado: PASSED (El servidor procesa la solicitud manteniendo el rol asignado por defecto con éxito).

• TC-SEC-ROL-02 (Prevención de Escalada de Privilegios por Administrador):

  • Política relacionada: POL-SEC-03.
  • Descripción: Verificar que un usuario con rol administrador, pueda elevar los privilegios de un usuario con rol Docente a rol Administrador alterando el JSON del campo rol en petición PUT hacia la API de usuarios.
  • Diseñado por: Ignacio Bentivoglio.
  • Ejecutado por: M. Florencia Lorenzati.
  • Resultado: PASSED (El servidor procesa la solicitud asignando el rol dado por el admin).

• TC-SEC-04 (Validación de emisión de Token JWT y ciclo de vida de acceso):

  • Política relacionada: POL-SEC-02.
  • Descripción: Comprueba que el backend de Django procese correctamente las credenciales y emita el par de tokens (access y refresh) con los tiempos de expiración configurados.
  • Diseñado por: Carlos Balbastro.
  • Ejecutado por: Kiara Fernandez.
  • Resultado: PASSED (El servidor responde con código 200 OK y devuelve un JSON con los tokens access y refresh para su almacenamiento local).

• TC-SEC-05 (Validación de rechazo de acceso no autorizado en endpoints protegidos GET/PUT):

  • Política relacionada: POL-SEC-02.
  • Descripción: Comprueba que el backend bloquee de forma estricta cualquier intento de lectura o modificación del perfil sin un token JWT válido o vigente.
  • Diseñado por: Eric Heredia.
  • Ejecutado por: Kiara Fernandez.
  • Resultado: PASSED (El backend deniega el acceso al recurso protegido y devuelve el mensaje de error de credenciales no provistas).

• TC-SEC-06 (Integración del cliente Android en lectura y actualización de perfil con JWT):

  • Política relacionada: POL-SEC-02.
  • Descripción: Comprueba que la interfaz Android inyecte de forma transparente el token en el encabezado HTTP y gestione correctamente la respuesta del servidor.
  • Diseñado por: Darío Bosque.
  • Ejecutado por: Kiara Fernandez.
  • Resultado: PASSED (La solicitud viaja con el token Bearer, el servidor procesa los cambios, responde 200 OK y la interfaz refleja los datos actualizados).

• TC-SEC-07 (Validación de cierre de sesión seguro y purga de credenciales locales):

  • Política relacionada: POL-SEC-02.
  • Descripción: Cierre de sesión local, redirección a IngresoActivity y bloqueo de navegación hacia atrás.
  • Diseñado por: Kiara Fernandez.
  • Ejecutado por: Kiara Fernandez.
  • Resultado: PASSED (La app elimina la sesión almacenada, redirige exitosamente a la pantalla de IngresoActivity y restringe el botón de retroceso impidiendo reingresar a la sesión).

---

• Pull Request #90 Implementación de autenticación JWT (aporte, parte de jwt ya estaba realizado por mis compañeros), serializador personalizado, permisos granulares y guards iniciales en Angular. (María Florencia Lorenzati).

• Pull Request #94 Corrección y blindaje integral contra la vulnerabilidad IDOR (Backend + Frontend + Limpieza de interfaz). (María Florencia Lorenzati).

• Pull Request #88 Implementación de protección en serializadores y prevención de escalada de privilegios frente a modificación de roles por métodos PUT. (Ignacio Martín Bentivoglio).