Al modificar el backend, bloquea ataques desde archivos subidos y datos del usuario

## Antes de cambiar el código, sigue los datos externos y busca rutas de código similares Supón que los archivos cargados, el contenido de los archivos comprimidos, los parámetros de solicitud, los manifiestos, los metadatos y los identificadores de dispositivos pueden estar controlados por un atacante, incluso cuando el usuario esté autenticado. Antes de cambiar una ruta de código sensible: 1. Identifica por dónde entran los datos no confiables, cómo se transforman y todas las operaciones de archivos, procesos, bases de datos, renderizado, redirecciones y red a las que pueden llegar. 2. Busca implementaciones relacionadas que realicen la misma operación. Incluye formatos alternativos, vistas de API y web, flujos binarios y de código fuente, y puntos de llamada heredados. 3. Reutiliza o amplía las funciones auxiliares de seguridad centralizadas en lugar de dispersar comprobaciones improvisadas entre vistas y controladores. 4. Revisa los patrones de vulnerabilidades anteriores cuando estén disponibles, sobre todo las correcciones incompletas que solo protegían una ruta. 5. Mantén coherentes las importaciones y las convenciones locales; después, ejecuta el lint requerido y las pruebas específicas hasta que finalicen correctamente. Una corrección de seguridad está incompleta si una ruta equivalente todavía puede llegar a la operación vulnerable. ## Valida los datos de solicitudes y las subidas en la entrada, y exige inicio de sesión y permisos Valida la entrada sin procesar antes de que se convierta en una ruta, un argumento de comando, un valor de consulta, una redirección, una cadena renderizada o un host de salida. - Usa formularios o esquemas con tipos como capa principal de validación. - Usa campos de selección finita para los parámetros cuyo conjunto de valores válidos sea conocido. - Coloca la lógica de rechazo específica de cada campo en la capa de validación y devuelve una respuesta de error estándar cuando falle la validación. - Valida los identificadores según su formato exacto antes de usarlos en rutas o búsquedas. - Comprueba los bytes mágicos, los límites de tamaño y las listas de extensiones permitidas de las cargas; una extensión por sí sola no es suficiente. - Trata los valores de manifiestos y metadatos como entradas no confiables. Los controladores sensibles deben aplicar todos los controles pertinentes: - autenticación; - autorización por rol o permiso; - restricción explícita del método HTTP; - protección CSRF para los cambios de estado iniciados desde el navegador. No desactives el escape de plantillas ni marques como seguro el contenido no confiable. Al construir una salida fuera de una plantilla con escape automático, codifica el valor según el contexto de destino. ## Mantén las rutas de archivos y la extracción de ZIP/TAR dentro de la carpeta prevista Usa dos capas para las rutas del sistema de archivos: 1. Rechaza formas sin procesar peligrosas, como segmentos de recorrido, rutas absolutas, evasiones codificadas y caracteres no válidos. 2. Después de construir la ruta, resuélvela de forma canónica y verifica que permanezca dentro de la raíz prevista. Antes de leer un objeto del sistema de archivos, rechaza enlaces simbólicos, canalizaciones con nombre, archivos de dispositivo y otros tipos inesperados cuando la operación espere un archivo normal. Para extraer TAR: - Prefiere un filtro de extracción proporcionado por el entorno de ejecución, aplicado por miembro y consciente del tipo, que rechace recorridos, rutas absolutas, archivos de dispositivo y enlaces que salgan del destino. - No dependas de una comprobación basada solo en el nombre o en `abspath`; no resuelve los enlaces simbólicos. - Si no hay un filtro integrado seguro, rechaza los enlaces simbólicos y duros, resuelve el destino con `realpath` y valida inmediatamente antes de extraer cada miembro. - Evita validar todo el lote y después extraerlo, porque el estado del sistema de archivos puede cambiar entre ambas fases. Para extraer ZIP: - Valida cada nombre de miembro para detectar recorridos antes de extraerlo. - Resuelve el destino propuesto y verifica que esté contenido dentro de la raíz de extracción. - Extrae el miembro solo después de que supere ambas comprobaciones. Toda protección que falle debe detener la operación insegura mediante `continue`, `return` o `raise`. Registrar una advertencia sin bloquear la ejecución no constituye un control de seguridad. ## Neutraliza la entrada del usuario según dónde se use, como en SQL o comandos de shell - Pasa los argumentos del subproceso como una lista. Nunca insertes entradas no confiables en una cadena de comando del shell. - Usa operaciones parametrizadas del ORM o del generador de consultas. Nunca construyas SQL mediante formato de cadenas. - Escapa el contenido controlado por el usuario antes de renderizarlo fuera de un contexto con escape automático. - Sanea los formatos activos, como SVG, antes de mostrarlos. - Elimina los saltos de línea y los caracteres de control de los campos de registro derivados del usuario para evitar la inyección en registros. - Genera nombres de archivo seguros antes de colocarlos en las cabeceras de respuesta. - Permite únicamente destinos de redirección relativos y validados. - Antes de realizar solicitudes salientes, resuelve y valida el host, y rechaza las direcciones de bucle invertido, privadas, locales de enlace, multidifusión y otros intervalos prohibidos. Aplica una validación específica para cada contexto en lugar de un único saneador genérico. Un valor seguro para un filtro de base de datos todavía puede ser inseguro en un nombre de archivo, un comando del shell, un fragmento HTML, una entrada de registro, una redirección o una URL. ## Termina con una lista de comprobación de seguridad y muestra evidencia de cada punto Para cada cambio que implique E/S de archivos o entradas del usuario, verifica los elementos pertinentes: - [ ] La entrada sin procesar se valida antes de construir la ruta. - [ ] Las rutas construidas se contienen de forma canónica dentro de la raíz prevista. - [ ] Los enlaces, las canalizaciones y los tipos de archivo inesperados se rechazan antes de la lectura. - [ ] Los miembros de los archivos comprimidos se validan individualmente antes de extraerlos. - [ ] Los argumentos del shell se pasan sin interpolarlos en cadenas. - [ ] Los valores renderizados se escapan y el contenido activo se sanea. - [ ] Se restringen los hosts de salida y los destinos de redirección. - [ ] Se sanean los valores de registro derivados del usuario. - [ ] El acceso a la base de datos usa operaciones parametrizadas. - [ ] Cada rama de rechazo impide la operación peligrosa. - [ ] Las rutas de código equivalentes reciben la misma corrección. - [ ] Las pruebas específicas cubren entradas aceptadas, entradas rechazadas e intentos de evasión. - [ ] El lint y las pruebas pertinentes finalizan con el código de salida cero. Informa de las pruebas que respaldan cada comprobación completada e identifica cualquier ruta que no se haya podido verificar.