framework
9 artículos con esta etiqueta
Seguridad de ASP.NET Core — errores en producción, secretos y autorización
ASP.NET Core es una base madura y sólida, pero los incidentes vienen de la configuración. Los tres grandes: (1) exponer errores detallados / la Developer Exception Page en producción (fuga de información interna), (2) secretos incrustados en appsettings.json (usa User Secrets / variables de entorno / Key Vault), (3) atributos de autorización ausentes ([Authorize]). Además, deserialización insegura (BinaryFormatter, etc.), over-posting en el model binding (limita con DTO/[Bind]) y CVE de dependencias NuGet. Defensas: oculta los errores detallados en prod, carga los secretos fuera de la configuración, haz explícita la autorización.
Seguridad de Django — DEBUG, SECRET_KEY y autorización
Django viene 'con las pilas incluidas' y valores por defecto seguros (ORM, CSRF, autoescape de plantillas, auth) y es sólido si se configura correctamente. Pero los incidentes vienen de la configuración. Los tres grandes: (1) DEBUG=True en producción que expone ajustes, variables de entorno y secretos en la página de error, (2) una SECRET_KEY filtrada (la base de firmas/sesiones), (3) autorización débil (faltan comprobaciones de is_staff/permission). Además, SQLi por raw()/extra() o interpolación de cadenas, deserialización insegura (pickle), ALLOWED_HOSTS sin configurar y CVE de dependencias (pip). Defensas: DEBUG=False en prod, SECRET_KEY desde el entorno, autorización explícita.
Seguridad de Express (Node.js) — las defensas que añades tú mismo
Express es minimalista: casi no trae funciones de seguridad por defecto, así que las defensas son las que añade el desarrollador. Lo esencial: (1) cabeceras de seguridad (estilo helmet), (2) validación y saneamiento de la entrada, (3) autorización acotada al propietario, no solo autenticación, (4) limitación de tasa (fuerza bruta / DoS), (5) monitoreo de CVE de dependencias (npm) y parcheo rápido. Además, protección SSRF para las peticiones salientes de URL y secretos guardados en variables de entorno, fuera del código. La libertad de un framework mínimo viene con la responsabilidad de defender.
Seguridad por framework — defensas específicas para la tecnología que usas
Sea cual sea el framework que uses, los *tipos* de debilidad que atacan los agresores son en gran medida los mismos (control de acceso, secretos, inyección, CVE de dependencias, mala configuración). Lo que cambia son los 'valores por defecto peligrosos' y 'el punto más atacado' de cada framework. Este sitio ofrece, por framework, los fallos por defecto y los pasos de hardening. Empieza por el capítulo de la tecnología que de verdad usas.
Seguridad de Laravel — exposición de .env, APP_DEBUG y autorización
Laravel trae valores por defecto bastante seguros, pero la mayoría de los incidentes vienen de la operación. Los tres grandes fallos: (1) .env o archivos de secretos alcanzables por URL desde el directorio público, (2) APP_DEBUG=true en producción exponiendo variables de entorno e info de conexión en la página de error, (3) autorización ausente (inicio de sesión = autenticación, pero sin autorización con alcance de propietario / Mass Assignment sobrescribiendo campos no previstos). Defensas: secretos fuera de public con permisos 600, debug apagado + caché de config en prod, autoriza con Policy/Gate, declara $fillable.
Seguridad de Next.js — Server Actions, variables de entorno y CVE de dependencias
Next.js trae valores por defecto bastante seguros, pero los incidentes ocurren en la frontera servidor/cliente. Los tres grandes: (1) exposición de variables de entorno (mal uso de NEXT_PUBLIC_ o pasar secretos server-only al cliente), (2) autorización ausente en Server Actions / Route Handlers (autenticado pero sin delimitar por propietario) y (3) CVE conocidos de dependencias (incluido RCE en el núcleo del framework — juzga por la versión en ejecución y parchea rápido). Defensas: mantén los secretos en el servidor, cuida la frontera, autoriza en cada acción, monitorea los CVE de dependencias con una máquina.
Seguridad de Ruby on Rails — Strong Parameters, autorización y CVE de gems
Rails trae convenciones y valores por defecto seguros (protección CSRF, Strong Parameters, un ORM) y es sólido si se usa correctamente. Pero los incidentes vienen de la operación. Los tres grandes: (1) Strong Parameters demasiado permisivos que permiten Mass Assignment (sobrescribir is_admin, etc.), (2) autorización débil (login = autenticación, pero sin ámbito de propietario), (3) CVE conocidos de gems (dependencias). Además, SQLi por interpolación de cadenas en where, métodos dinámicos peligrosos (send/constantize) y fuga de credentials/secret_key_base. Defensas: ajustar el permit, hacer explícita la autorización, monitorear los CVE de gems.
Seguridad de Spring Boot — CVE de dependencias, exposición de Actuator y autorización
Spring (Spring Boot) es un básico empresarial. Tipos de incidente: (1) CVE conocidos de dependencias (un fallo de base ampliamente heredado como Log4Shell — juzga por la versión en ejecución y parchea rápido), (2) endpoints de gestión/diagnóstico como Actuator expuestos (fuga de información / operación), (3) autorización ausente en Spring Security (autenticado pero con comprobaciones de permiso débiles), (4) deserialización insegura. Defensas: monitorea con una máquina y parchea rápido los CVE de dependencias, blinda las superficies de Actuator/gestión, haz explícita la autorización, no deserialices datos no confiables.
Seguridad de WordPress — por qué es atacado y las defensas mínimas
WordPress tiene la mayor cuota, así que estadísticamente es el mayor objetivo. Los puntos de entrada son menos el núcleo que las vulnerabilidades de complementos/temas, las actualizaciones omitidas, los administradores débiles/reutilizados y las superficies de administración expuestas (wp-admin/xmlrpc/enumeración REST). Defensas: automatiza las actualizaciones del núcleo y complementos, elimina complementos/temas no usados, contraseña fuerte + 2FA para administradores, limita la exposición del panel y los intentos de inicio de sesión, detección de manipulación más copias de seguridad sin conexión.