Pentest de caja blanca (white box): guía para SaaS y fintech

El pentest de caja blanca (white box) es la prueba de penetración en la que el investigador de seguridad recibe acceso al código fuente, a la documentación de la arquitectura y a las personas del equipo, además de cuentas de prueba. Lee el código buscando caminos de ataque y confirma cada sospecha explotando la aplicación en ejecución. Es la modalidad más profunda: revela fallas que desde afuera tardarían semanas en aparecer, o nunca aparecerían.

Esta guía cierra la serie sobre las tres modalidades de pentest. Aquí verás qué encuentra la caja blanca que las otras no (con ejemplos de código vulnerable y corregido), cómo funciona en la práctica, cuándo vale la pena, cuándo no y cuánto cuesta.

Qué es el pentest de caja blanca, en una definición

El pentest de caja blanca es la simulación de un ataque hecha por alguien que conoce el sistema por dentro: el código, las reglas de negocio, la infraestructura y las integraciones. En lugar de descubrir la aplicación por prueba y error, como en la caja negra, el investigador usa el código como mapa: identifica dónde se toman las decisiones de seguridad (quién puede ver qué, cómo se mueve el dinero, de dónde vienen los datos) y comprueba si cada una resiste a un atacante.

El propio OWASP respalda este enfoque. En el ASVS 4.0.3 (el estándar de verificación de seguridad de aplicaciones), el nivel 1 se describe como el único totalmente comprobable sin acceso al código; los niveles 2 y 3 requieren acceso a documentación, código fuente, configuración y a las personas involucradas en el desarrollo. El estándar incluso recomienda reemplazar las pruebas puramente externas por pentests guiados por el código.

Caja blanca vs caja gris vs caja negra

Las tres modalidades responden preguntas distintas:

Las otras dos están explicadas en detalle en pentest de caja negra y pentest de caja gris.

Qué encuentra la caja blanca que las otras no

Los ejemplos de abajo son patrones recurrentes en SaaS y fintech. En todos, la prueba externa podría llegar a la falla, pero depende de la suerte, de muchos intentos o de que la ruta sea visible en la interfaz. Leyendo el código, aparece de una vez, junto con todas sus variantes.

1. Endpoint sin control de autorización (CWE-639)

El endpoint confía en el identificador que llega en la URL y no verifica si el recurso pertenece a quien lo pide: el conocido BOLA/IDOR. Desde afuera, encontrarlo exige dos cuentas y adivinar identificadores. En el código, el investigador ve todas las rutas que consultan la base de datos sin filtrar por tenant, incluso las que ninguna pantalla usa.

// Vulnerable: busca la factura solo por el id de la URL
app.get("/api/invoices/:id", auth, async (req, res) => {
  const invoice = await db.invoice.findUnique({ where: { id: req.params.id } });
  res.json(invoice);
});

// Corregido: el filtro incluye el tenant del usuario autenticado
app.get("/api/invoices/:id", auth, async (req, res) => {
  const invoice = await db.invoice.findFirst({
    where: { id: req.params.id, tenantId: req.user.tenantId },
  });
  if (!invoice) return res.sendStatus(404);
  res.json(invoice);
});

Referencia: CWE-639 — Authorization Bypass Through User-Controlled Key.

2. Secretos en el código y en el historial de Git (CWE-798)

Clave de API de pagos, contraseña de base de datos, token de un servicio de correo. Aunque el equipo lo borre del código, el secreto sigue en el historial del repositorio, y en cualquier copia de él. Una prueba externa rara vez llega ahí; la revisión de código sí, y la corrección incluye rotar la clave, no solo borrar la línea.

// Vulnerable: la clave queda en el código y en el historial de Git
const stripe = new Stripe("sk_live_XXXXXXXXXXXX");

// Corregido: secreto en variable de entorno o bóveda, con rotación
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

Referencia: CWE-798 — Use of Hard-coded Credentials.

3. Tokens predecibles (CWE-330)

Enlace para restablecer contraseña, invitación, confirmación de correo: si el token se genera con una función que no es criptográficamente segura, se puede predecir. Desde afuera es casi invisible, porque el token parece aleatorio. En el código, es una línea.

// Vulnerable: Math.random no sirve para secretos
const resetToken = Math.random().toString(36).slice(2);

// Corregido: generador criptográfico
import { randomBytes } from "node:crypto";
const resetToken = randomBytes(32).toString("hex");

Referencia: CWE-330 — Use of Insufficiently Random Values.

4. Deserialización de datos externos (CWE-502)

Cuando la aplicación reconstruye objetos a partir de datos que vienen de afuera (cookie, cola, caché, archivo subido) con un formato que permite ejecutar código, el resultado puede ser ejecución remota en el servidor. El punto vulnerable suele estar lejos de la pantalla, en una integración o en un proceso en segundo plano, y es justo lo que revela la lectura del código. La corrección es usar formatos que no ejecutan código (como JSON), validar el contenido y firmar lo que debe volver íntegro. Referencia: CWE-502 — Deserialization of Untrusted Data.

5. Rutas olvidadas y lógica oculta

Un endpoint de depuración que quedó en producción, una ruta de una versión antigua de la API, una feature flag que habilita funciones de administrador, un proceso interno que acepta llamadas externas. Nada de eso aparece en la interfaz, por eso pasa inadvertido en caja negra y muchas veces en caja gris. Con el código, el investigador lista todas las rutas registradas y prueba cada una.

6. Dependencias vulnerables que de verdad se usan

Los analizadores de dependencias listan decenas de librerías con CVE. Lo que importa es si el fragmento vulnerable es llamado por tu código, con datos que controla el atacante. La revisión de caja blanca responde eso y convierte una lista larga en pocos ítems que realmente exigen acción.

Cómo funciona en la práctica

1. Alcance y acceso. Se define qué entra (repositorios, módulos, ambiente de prueba, cuentas) y una versión fija del código, para que los hallazgos apunten a archivos y líneas estables.
2. Arquitectura y flujos críticos. Autenticación, autorización, movimiento de dinero, datos personales e integraciones con terceros: ahí se concentra el riesgo.
3. Revisión guiada por riesgo. No es leer cada línea del sistema: es seguir los caminos que usaría un atacante, desde las entradas externas hasta las decisiones de seguridad.
4. Validación en la aplicación en ejecución. Cada sospecha se convierte en una prueba real. Solo entra al informe lo que tiene prueba de explotación (o una justificación técnica clara).
5. Informe y re-test. Cada hallazgo con archivo y línea, impacto, pasos para reproducirlo y corrección sugerida; después de las correcciones, re-test.

Por qué no es solo ejecutar una herramienta SAST

Las herramientas de análisis estático (SAST) son útiles en el día a día, dentro del pipeline de CI. Pero señalan patrones, no ataques: generan falsos positivos, no entienden reglas de negocio (“el usuario del plan gratuito no puede exportar informes”) y no saben si un fragmento es alcanzable por un atacante. En el pentest de caja blanca, la herramienta es apoyo: quien decide qué es una falla, y lo prueba, es el investigador. La OWASP Code Review Guide es una buena referencia sobre cómo combinar revisión manual y herramientas.

Cuándo contratar caja blanca

1. Fintech y medios de pago

Los flujos de dinero dejan poco margen de error. Para quien procesa tarjetas, PCI DSS v4.0 (requisito 6.2.3) exige que el software desarrollado a medida se revise antes de pasar a producción, para encontrar y corregir vulnerabilidades de código. El texto oficial está en la biblioteca de documentos del PCI SSC. Para el contexto regulatorio de Brasil, consulta pentest para fintech y pentest para medios de pago.

2. Módulos críticos nuevos o reescritos

Autenticación, permisos, facturación, billetera, pagos instantáneos, motor de reglas: cuando uno de estos módulos nace o cambia mucho, revisar el código antes del lanzamiento cuesta mucho menos que descubrir la falla en producción.

3. Due diligence, clientes enterprise o auditoría

Inversionistas, compradores y clientes grandes piden cada vez más evidencia de pruebas de seguridad. Un informe de caja blanca, con alcance y metodología claros, es una evidencia sólida, sin prometer una certificación, que depende del auditor y del marco elegido.

4. Después de un incidente

Corregir el punto explotado no alcanza: la misma falla suele existir en otros lugares del código. La revisión de caja blanca encuentra las variantes y la causa raíz.

5. Código heredado o tercerizado

Un sistema comprado, un equipo que cambió, un proveedor que entregó y se fue. Antes de asumir el riesgo, conviene saber qué hay adentro.

Cuándo no es la mejor opción

• Cuando la pregunta es “¿qué ve un atacante externo?”: para validar la superficie expuesta, la caja negra responde mejor y más rápido.
• Cuando el presupuesto es ajustado y la aplicación es grande: una caja gris enfocada en autorización y lógica de negocio suele rendir más por hora.
• Cuando no hay acceso al código: por ejemplo, un SaaS de terceros que usas. Ahí la prueba posible es caja negra o gris, dentro de las reglas del proveedor.

Qué exigir a quien va a ver tu código

Entregar el código es entregar el mapa del sistema. Antes de dar acceso, exige: NDA firmado antes de cualquier acceso; acceso de solo lectura y por tiempo limitado; nada de copias fuera del ambiente acordado; y eliminación comprobada al final del proyecto. Una empresa seria acepta estas condiciones sin discutir.

Cuánto cuesta un pentest de caja blanca

En No Vuln, el pentest se contrata por horas, con una tarifa de US$ 150 a US$ 250 por hora. Como la caja blanca incluye lectura de código además de las pruebas, suele usar paquetes más grandes: el Deep Dive (50h), de US$ 7.500 a US$ 12.500, para un producto o módulo crítico, y el Full Scope (100h+), desde US$ 15.000, para sistemas más grandes o varias aplicaciones. Las horas dependen del tamaño del código en el alcance y de la cantidad de flujos críticos.

Para comparar con el mercado, consulta cuánto cuesta un pentest en Brasil y el costo por tamaño de SaaS B2B.

Cómo combinar caja blanca con caja gris y caja negra

Las modalidades se complementan. Una combinación común en SaaS y fintech maduros: caja blanca en los módulos críticos y en cada cambio grande de arquitectura; caja gris como prueba recurrente de toda la aplicación; caja negra para seguir la superficie expuesta entre un ciclo y otro. Así el presupuesto va a la profundidad donde el riesgo es mayor, sin dejar el resto descubierto.

Qué hacer ahora

1. Lista los módulos donde una falla costaría más (dinero, datos personales, permisos).
2. Revisa cuándo fue la última vez que alguien externo leyó ese código con mirada de atacante.
3. Busca secretos en el repositorio y en su historial, y rota los que encuentres.
4. Incluye SAST y verificación de dependencias en el CI, como red de protección continua.
5. Para los módulos críticos, planifica un pentest de caja blanca antes de la próxima gran entrega.

Para el alcance técnico del pentest en SaaS, consulta pentest para SaaS. Si quieres hablar de tu caso: habla con un investigador, con NDA bilateral antes de la primera llamada técnica.