misconfiguration
10 artículos con esta etiqueta
Exposición pública del almacenamiento en la nube: cuando los datos pueden filtrarse aunque Block Public Access esté activado
Las filtraciones de buckets vienen de la configuración, no de un ataque. La frase clave de la documentación: los ajustes de bloqueo del acceso público no modifican las políticas ni las ACL existentes; los ajustes públicos siguen debajo del bloqueo y, si se quita el bloqueo, vuelve el acceso público. Por eso el objetivo no es «el bloqueo está activado», sino «nada es público aunque se desactive el bloqueo». Aplícalo a nivel de cuenta, porque una política de bucket puede dar a alguien la capacidad de desactivar el bloqueo a nivel de bucket. Y «público» se define de forma más amplia de lo que se suele pensar.
4 errores de seguridad habituales: configuración por defecto, servicios olvidados, falta de monitorización y confiar demasiado en la validación de entradas
Los incidentes salen de un pequeño conjunto de patrones que se repiten, y esos patrones se ven más claros ordenados por creencia que por tecnología. Son cuatro: lo que viene por defecto será seguro (no se configuró nada), lo que no se usa será inofensivo (no se cerró nada), nos daríamos cuenta (no hay nada observable) y la entrada validada será segura (se dejó demasiado en manos de la entrada). Ninguno necesita grandes conocimientos técnicos para corregirse; necesitan el hábito de comprobar. Aquí tienes qué revisar en cada uno.
Seguridad en ASP.NET Core — una referencia de endurecimiento para producción
ASP.NET Core es un framework maduro y estable, 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.
Seguridad en Django — una referencia de endurecimiento para producción
Django incluye muchos 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 un framework estable, 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.
¿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 archivo. 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): mala configuración del proxy de confianza y cómo defenderse
XFF es un encabezado falsificable por el cliente. Un escáner indiscriminado mete sondeos de inyección en un XFF suplantado, y el ajuste 'confiar en todos los proxies (comodín)' lo deja pasar. Solución a corto plazo: sanear el encabezado de IP en el límite. Solución de fondo: confiar solo en los proxies correctos (o en ninguno). El impacto cero aun así dejó un ajuste por arreglar.
Un caso en que el .env de Laravel era legible públicamente: un error de ubicación en hosting compartido y cómo corregirlo
La causa: toda la app estaba bajo la raíz web; solo public/ debería ser visible. Corrige en tres pasos — un bloqueo temporal con .htaccess, rotar claves, reestructurar — y luego prevenlo con proceso.