75 pruebas de seguridad: cómo verificamos todo

Construir funciones de seguridad es la mitad de la batalla. Probar que funcionan es la otra mitad. Una función de hash que silenciosamente retorna una cadena vacía. Un limitador de tasa que se reinicia en cada solicitud. Un guard que aprueba cuando debería fallar. Un verificador JWT que acepta tokens expirados. Cada uno de estos errores es invisible en operación normal y catastrófico en un escenario de ataque.

Escribimos 75 pruebas enfocadas en seguridad para el runtime de FLIN, organizadas en diez categorías. Cada prueba es una función Rust #[test] que ejercita un comportamiento de seguridad específico y verifica que funcione correctamente. Sin mocking. Sin stubs. Operaciones criptográficas reales, generación de tokens real, contadores de limitación de tasa reales.

Este artículo documenta las categorías de pruebas, muestra pruebas representativas de cada una y explica la filosofía de testing que nos guió.

Organización de pruebas

Las 75 pruebas están organizadas en diez categorías:

tests/security/
    password_hashing.rs      -- 12 pruebas
    jwt_tokens.rs            -- 10 pruebas
    rate_limiting.rs         -- 8 pruebas
    guards.rs                -- 10 pruebas
    csrf.rs                  -- 5 pruebas
    input_validation.rs      -- 12 pruebas
    session_security.rs      -- 6 pruebas
    security_headers.rs      -- 4 pruebas
    file_upload_security.rs  -- 4 pruebas
    cryptographic_safety.rs  -- 4 pruebas

Cada archivo de pruebas se enfoca en un dominio de seguridad y prueba tanto el camino feliz (la función funciona correctamente) como el camino de ataque (la función resiste el mal uso).

Categoría 1: Hashing de contraseñas (12 pruebas)

Las pruebas de hashing verifican el comportamiento de Argon2id de extremo a extremo:

rust#[test]
fn test_hash_produces_argon2id_format() {
    let hash = hash_password("test-password").unwrap();
    assert!(hash.starts_with("$argon2id$"));
}

#[test]
fn test_correct_password_verifies() {
    let hash = hash_password("correct-horse-battery-staple").unwrap();
    assert!(verify_password("correct-horse-battery-staple", &hash).unwrap());
}

#[test]
fn test_wrong_password_fails() {
    let hash = hash_password("correct-password").unwrap();
    assert!(!verify_password("wrong-password", &hash).unwrap());
}

#[test]
fn test_same_password_different_hashes() {
    let hash1 = hash_password("same-password").unwrap();
    let hash2 = hash_password("same-password").unwrap();
    assert_ne!(hash1, hash2); // Sales diferentes -> hashes diferentes
}

La prueba de hashes diferentes de la misma contraseña es crítica -- verifica que el salting funciona. Si dos hashes de "password" son idénticos, la generación de sal está rota y los ataques de tabla arcoíris son posibles.

La filosofía de testing

Tres principios guiaron nuestras pruebas de seguridad:

Probar la ruta de fallo. La mayoría de las pruebas verifican que la entrada inválida sea rechazada. Esto es contraintuitivo -- los desarrolladores usualmente prueban que la entrada válida funciona. Pero la seguridad se trata de lo que sucede cuando las cosas salen mal.

Sin mocking para operaciones criptográficas. Las pruebas de hashing usan Argon2id real. Las pruebas JWT usan HMAC-SHA256 real. Mockear una función criptográfica anula el propósito de probarla.

Independencia de pruebas. Cada prueba crea su propio estado, ejecuta su aserción y limpia. Las pruebas pueden ejecutarse en cualquier orden, en paralelo, sin afectarse mutuamente.

Ejecución de las pruebas

bashcargo test --test security -- --test-threads=4

Las 75 pruebas se completan en menos de 10 segundos. Las pruebas de hashing son las más lentas (Argon2id con 64 MB de memoria toma aproximadamente 200 ms por hash), pero incluso estas se completan lo suficientemente rápido para que el conjunto de pruebas se ejecute en cada commit.

Las pruebas de seguridad no son opcionales. Se ejecutan en CI junto con las pruebas unitarias y de integración. Una regresión de seguridad rompe la compilación.

Esta es la Parte 114 de la serie "Cómo construimos FLIN", que documenta cómo un CEO en Abidjan y un CTO de IA diseñaron y construyeron un lenguaje de programación desde cero.

Navegación de la serie: - [113] Validadores de cuerpo de solicitud - [114] 75 pruebas de seguridad: cómo verificamos todo (estás aquí) - [115] Guards y middleware de seguridad personalizados - [116] El motor de intenciones: consultas de base de datos en lenguaje natural