misconfiguration
8 artículos con esta etiqueta
Seguridad en Django — una referencia de endurecimiento para producción
Django viene «con pilas incluidas» y valores por defecto seguros (ORM, CSRF, autoescapado, auth), pero los incidentes vienen de la configuración. Esta es una referencia de trabajo: (1) una lista de endurecimiento ordenada por prioridad (P0–P2), (2) guía por área — DEBUG=False + ALLOWED_HOSTS, externalizar SECRET_KEY, CVE de dependencias pip, configuración de seguridad de producción (SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE, etc.), autorización (alcance de propietario), inyección y salida (raw/extra, mark_safe), CSRF/sesiones/admin, SSRF/subidas, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.
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 — una referencia de hardening para producción
Los valores por defecto de Laravel son sólidos; los incidentes de producción vienen de la configuración y la operación. Esta es una referencia de trabajo: (1) un checklist de hardening ordenado por prioridad (P0–P2), (2) una tabla de valores por defecto peligrosos, (3) guía por área — secretos/APP_KEY, config de producción (APP_DEBUG/caché), autorización (Policy/Gate, Mass Assignment), inyección/salida (binding de Eloquent, Blade), sesiones/CSRF/cookies, subidas de archivos, HTTPS/cabeceras/limitación de tasa, CVE de dependencias de Composer, y (4) un checklist de autoverificación. Solo defensivo — sin pasos de ataque.
Seguridad de Spring Boot — una referencia de hardening para producción
Spring Boot es una base sólida, pero los incidentes vienen de las dependencias, la configuración y la autorización. Esta es una referencia práctica: (1) una lista de comprobación de hardening ordenada por prioridad (P0–P2), (2) guía por área — CVE de dependencias (de tipo Log4Shell, juzgados por la versión en ejecución), configuración de producción y secretos externalizados, autorización con Spring Security (denegación por defecto/seguridad a nivel de método/comprobaciones de propietario), reducción de la exposición de Actuator/gestión, deserialización insegura, inyección, cabeceras/CSRF/sesión, SSRF, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.
Seguridad en ASP.NET Core — una referencia de endurecimiento para producción
ASP.NET Core es una base madura y sólida, pero los incidentes vienen de la configuración. Esta es una referencia de trabajo: (1) una lista de endurecimiento ordenada por prioridad (P0–P2), (2) guía por área — no exponer errores detallados / la Developer Exception Page en producción, externalizar secretos (User Secrets/env/Key Vault), CVE de dependencias NuGet, autorización ([Authorize], denegación por defecto de reserva, basada en recurso/propietario), over-posting (DTOs/[Bind]), deserialización insegura (evitar BinaryFormatter), HTTPS/cabeceras/antiforgery, SSRF, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.
¿Dejaste un archivo de secretos en un directorio público? Audita tu webroot
Cualquier cosa en tu webroot puede descargarse por URL por cualquiera. Un JSON de token/credenciales olvidado, un .env o una copia de seguridad significa exposición instantánea — y si vino de una plantilla compartida, todos los sitios tienen el mismo agujero. Solución: coloca en el directorio público solo cosas compartibles públicamente, mantén los secretos fuera del webroot con permisos 600, y una vez que encuentres uno, audita cada sitio y servidor.
Qué es la suplantación de X-Forwarded-For (XFF) — la trampa de la configuración de proxy de confianza
XFF es un encabezado falsificable por el cliente. Un escáner ciego esconde sondeos de inyección en un XFF suplantado; 'confiar en todos los proxies (comodín)' lo deja pasar. Parche = sanear el encabezado de IP en el límite; solución raíz = confiar en los proxies correctos (o en ninguno). El impacto cero aun así dejó un ajuste por arreglar.
El .env de apps Laravel era legible por todo el mundo — el error más común del hosting compartido
La causa: toda la app estaba bajo la raíz web; solo public/ debería ser visible. Corrige en tres pasos — primeros auxilios con .htaccess, rotar claves, reestructurar — y luego prevenlo con proceso.