Newer
Older
Sunfish / DOC / SEGURIDAD.md
@Ivan Dominguez Ivan Dominguez 1 day ago 3 KB Pre 3.0 (definitions)

Seguridad

Diseño previsto; aún no implementado.

Qué es y qué no es

Sunfish es deliberadamente sencillo: HTTP y FTP en claro, para que funcione con cualquier cliente, incluidos los de hace treinta años. Está pensado para redes de confianza (una LAN doméstica, un taller, una red temporal).

  • Las contraseñas (HTTP Basic, FTP, panel de administración) y los ficheros viajan sin cifrar: cualquiera en la misma red puede verlos.
  • Para compartir con seguridad por redes que no son de confianza, existe un proyecto aparte con cifrado y claves por usuario; Sunfish no intenta cubrir ese caso.

Lo que sí se protege es el servidor y su disco frente a peticiones malintencionadas.

Medidas

Acceso al disco

  • Validación de rutas común a web, FTP y WebDAV (SHARES-Y-RUTAS.md): nada fuera de la carpeta del share, ni con .., ni con rutas absolutas, ni con enlaces simbólicos.
  • Permisos de escritura desactivados por defecto en cada share; solo se activan explícitamente.
  • Subidas a fichero temporal y renombrado al final; tamaño máximo opcional.
  • Se elimina la ejecución de programas en el servidor (existía en la 2.0).
  • No requiere administrador: el proceso tiene solo los permisos del usuario que lo ejecuta.

Web

  • Todo texto que se escribe en HTML o XML se escapa.
  • Ningún cambio por GET. Crear, renombrar, borrar, subir y todo el panel son POST (o PUT/DELETE/MKCOL/MOVE en WebDAV).
  • Anti-CSRF sin cookies (los navegadores antiguos pueden no tenerlas): cada formulario lleva un token. El token es un HMAC-SHA256 de (acción, share, ruta, hora en bloques de una hora) con una clave aleatoria generada en cada arranque. Otra web no puede leerlo, así que no puede falsificar el formulario.
  • Cabeceras X-Content-Type-Options: nosniff y Content-Security-Policy sencilla en modo moderno.
  • El HTML subido a un share se sirve tal cual (es la función "servir una web"), así que un share con Upload y Listing permite publicar páginas. Se avisa en la interfaz al activar las dos cosas a la vez.

Contraseñas

  • Se guardan con PBKDF2-SHA256 (Rfc2898DeriveBytes.Pbkdf2), con sal y muchas iteraciones. La 2.0 guardaba la del panel en claro.
  • Caché de credenciales: HTTP Basic reenvía la contraseña en cada petición, así que las ya verificadas se guardan en memoria (como HMAC, no en claro) durante un tiempo, para no recalcular PBKDF2 cada vez.
  • Intentos fallidos: retardo creciente y bloqueo temporal por IP, en web, FTP y panel.

Panel de administración

  • Desactivado por defecto. Necesita contraseña y una IP incluida en AllowFrom (por defecto, solo el propio equipo).
  • Cambiar la contraseña desde el panel exige la actual.

Red y recursos

  • Bind permite limitar las interfaces de escucha (p. ej. solo la de la LAN).
  • Límites de conexiones por IP, de tamaño de cabeceras, plazos de inactividad y peticiones por conexión.
  • FTP:
    • modo activo solo hacia la IP del cliente y a puertos ≥ 1024;
    • rango de puertos pasivos acotado.
  • WebDAV: sin PROPFIND de profundidad infinita; XML sin DTD.
  • ZIP de carpetas: se puede desactivar por share (Zip), porque una carpeta enorme supone mucho trabajo de disco.

Problemas de la 2.0 que se corrigen

2.0 3
Path.Combine(base, ruta) sin validar: se podía salir del share Validación común y comprobación de la ruta real
Nombres de fichero sin escapar en el HTML Escapado siempre
Borrar y renombrar por GET POST con token
Requería administrador; lo ejecutado heredaba la elevación Sin administrador; sin ejecución
Contraseña del panel en claro en la configuración PBKDF2
402 para "prohibido" 403