diseño
4 artículos con esta etiqueta
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.
Deserialización insegura: el riesgo de dejar que los datos externos elijan el tipo de objeto y cómo evitarlo
El peligro de la deserialización no es que lleguen valores malos, sino que algunos formatos dejan que los datos externos decidan qué tipo de objeto se construye. Por eso el daño no se queda en datos corruptos: OWASP enumera denegación de servicio, elusión del control de acceso y ejecución remota de código. Dos defensas: pasar a un formato de datos puro para que nada elija tipos por ti, y firmar los mensajes serializados para no restaurar nunca los que no estén firmados. Y algunos mecanismos no se pueden hacer seguros con configuración; la única solución es no usarlos.
Fallos de diseño en el restablecimiento de contraseña: 5 formas de perder una cuenta pese a un login fuerte, y cómo corregirlas
Un flujo de restablecimiento es un mecanismo para que alguien que no conoce la contraseña pueda fijar una nueva, lo que lo convierte en una vía de autenticación por derecho propio. Refuerza el login todo lo que quieras: si el restablecimiento es débil, esa es tu verdadera fuerza de autenticación. Cinco formas de fallo: tokens adivinables, tokens que nunca caducan, enlaces que siguen vivos en un buzón, enlaces cuyo destino se puede fijar desde fuera (cabecera Host) y respuestas que revelan si una cuenta existe. El paso clave al implementarlo es separar lo que la guía exige de las cifras que deja en tus manos.
Límite de peticiones y control de abusos: cómo diseñar límites que frenen la fuerza bruta y los costes desbocados
El límite de peticiones suele fallar no porque el límite fuera demasiado laxo, sino porque se hizo la pregunta equivocada. Tres preguntas: a quién cuentas (la IP se puede falsificar y la comparten usuarios reales, así que la identidad va primero), qué cuentas (contar solo peticiones no ve operaciones caras aisladas: coste, tamaño, número de registros) y qué pasa al llegar al tope (un bloqueo tosco es una denegación de servicio contra usuarios legítimos). NIST fija en 100 el máximo de fallos consecutivos y pide retrasos y CAPTCHA en lugar de dejar fuera a la gente; OWASP incluye los límites de gasto con terceros, el último control contra el daño económico.