Pentest de caja negra, gris o blanca: ¿cuál elegir?

Para la mayoría de las aplicaciones de negocio, un pentest de caja gris es el que más hallazgos da por día de trabajo: el equipo recibe cuentas de usuario para cada rol y parte de la documentación. La caja negra muestra solo lo que ve alguien de fuera, y la caja blanca añade el código fuente y la arquitectura, y encaja con el código crítico: pagos, inicio de sesión, permisos.

Abajo tienes los tres formatos explicados con palabras sencillas y con las definiciones de NIST y OWASP, una tabla comparativa, qué preparar para una caja gris y cuándo hace falta una caja blanca.

En resumen

• Caja negra (black box). El pentester solo conoce la dirección web o un rango de IP. Ve lo mismo que un atacante externo.
• Caja gris (grey box o gray box). El pentester recibe cuentas de prueba para cada rol y parte de la documentación, por ejemplo la descripción de la API. Así se ve qué podría hacer un cliente, un socio o un empleado.
• Caja blanca (white box). El pentester recibe el código fuente, una descripción de la arquitectura y contacto con los desarrolladores. Es la prueba más profunda.
• La caja negra gasta parte de los días pagados en reconocimiento y a menudo no llega a las funciones que están tras el login.
• Para aplicaciones web, APIs y apps móviles, empieza por un pentest de caja gris. Añade la caja blanca para el código donde un error cuesta dinero.

Los tres formatos con palabras sencillas

Estos nombres describen cuánto sabe el pentester del sistema al empezar. El glosario de NIST los define precisamente por el nivel de conocimiento:

• caja negra significa un método de prueba que no supone ningún conocimiento de la estructura interna ni de la implementación de lo que se evalúa ^[1];
• caja gris significa un método que supone cierto conocimiento de la estructura interna ^[2];
• caja blanca significa un método que supone un conocimiento explícito y amplio de la estructura interna y de la implementación ^[3].

La OWASP Web Security Testing Guide indica que al pentest se le suele llamar prueba de caja negra, y a continuación añade que en muchos casos el tester recibe una o varias cuentas válidas en el sistema ^[5]. Es decir, en la práctica la mayoría de los pentests de aplicaciones ya son de caja gris. NIST SP 800-115 describe la caja gris como la combinación de técnicas de caja blanca (análisis del código) y de caja negra (probar la aplicación en funcionamiento sin conocer el código) ^[4].

En inglés verás «grey box» y «gray box». Es lo mismo: la primera forma es británica y la segunda estadounidense.

Dicho de forma sencilla: en caja negra le das al pentester la dirección del edificio. En caja gris le das además las llaves de los pisos normales. En caja blanca añades los planos y el esquema eléctrico.

Comparación: qué recibe el equipo y qué descubres

Por qué la caja negra suele dar menos por el mismo dinero

Un pentest tiene un número limitado de días. El NCSC británico lo dice claramente: cuando no se da información al equipo, algunas vulnerabilidades pueden quedar sin descubrir en el tiempo asignado ^[6]. En caja negra el pentester gasta días en lo que tú podrías contarle en una llamada: qué roles hay, dónde está la API, con qué está construido el sistema.

La segunda razón pesa más. Sin cuentas, el pentester ve la página de login, el registro y las páginas públicas. Lo más valioso de una aplicación de negocio está tras el login: el área de cliente, los pagos, el panel de administración, la API de la app móvil. Los problemas graves suelen estar justo ahí: un cliente ve facturas de otro, un usuario normal ejecuta acciones de administrador. Para comprobarlo hacen falta al menos dos cuentas del mismo rol y cuentas de roles distintos.

El argumento de que «la caja negra es más realista» funciona peor de lo que parece. Un atacante de verdad no tiene un límite de cinco días. Si tu registro es abierto, consigue una cuenta de usuario en un minuto. Puede robar la contraseña de un empleado con phishing. La caja gris empieza directamente desde ese punto.

La caja negra es la opción correcta cuando la pregunta es justo esa: qué ve alguien de fuera. Por ejemplo, después de cambios en la infraestructura o para probar el perímetro externo.

Qué preparar para una caja gris

Cuanto mejor sea la preparación, más tiempo dedica el pentester a buscar vulnerabilidades y menos a adivinar:

• Cuentas de prueba para cada rol, dos por rol: cliente, gestor, administrador, socio. Dos cuentas del mismo rol sirven para comprobar el acceso a datos ajenos.
• Datos de prueba. Pedidos, facturas y documentos en cada cuenta. Una cuenta vacía no enseña nada.
• Descripción de la API. Una especificación OpenAPI (Swagger), una colección de Postman o al menos una lista de endpoints.
• Entorno. Un entorno de staging lo más parecido posible a producción, o producción con límites acordados. La diferencia y cómo elegir está en el artículo cómo prepararse para un pentest.
• Una persona de contacto durante la prueba y una forma rápida de pararla.

Qué se revisa exactamente en una aplicación web y una API lo explicamos en cómo comprobar la seguridad de una web y una API. Para apps móviles añade las builds de iOS y Android; los detalles están en pentest de aplicaciones móviles.

Cuándo hace falta una caja blanca

NIST SP 800-115 señala que, para aplicaciones propias, las técnicas de caja blanca suelen encontrar defectos de seguridad de forma más eficiente y rentable que las de caja negra. Pero no ven los problemas en la interacción entre componentes ni los que aparecen durante la compilación y la configuración ^[4]. OWASP añade otro límite: el código desplegado en el servidor puede ser distinto del que se revisó ^[5]. Por eso la caja blanca se combina con pruebas sobre el sistema en marcha.

La caja blanca hace falta cuando un fallo en el código cuesta dinero o acceso:

• lógica de pagos, cálculos, saldos, devoluciones;
• inicio de sesión, recuperación de contraseña, autenticación de dos factores;
• separación de acceso entre clientes, roles y organizaciones;
• criptografía propia o gestión de claves;
• un socio o un regulador pide una revisión de código.

Caja blanca no significa revisar todo el código. A menudo basta con ir a fondo en los módulos críticos y probar el resto del sistema como caja gris.

Pentest externo e interno: otra división

Caja negra, gris y blanca describen cuánto sabe el pentester. Externo e interno describen desde dónde ataca.

Según NIST SP 800-115, la prueba externa se hace desde fuera del perímetro de seguridad, normalmente desde internet. La interna se hace desde la red interna, como un empleado de confianza o un atacante que ya ha superado el perímetro. En las pruebas internas se suele dar al pentester el nivel de acceso de un usuario normal. Si hacen falta las dos, la externa suele ir primero, para que el pentester no conozca detalles internos que un atacante de fuera no tendría ^[4].

Las dos divisiones se combinan. Por ejemplo, el perímetro externo se prueba como caja negra y la red interna como caja gris con la cuenta de un empleado normal. La prueba interna se explica en detalle en pentest de red interna y Active Directory.

Regla de decisión

Elige caja negra si:

• quieres ver el perímetro externo con los ojos de alguien de fuera;
• has cambiado la infraestructura y quieres saber qué se ve ahora desde internet;
• la aplicación ya se probó como caja gris y la pregunta es solo sobre la superficie externa.

Elige caja gris si:

• tienes una aplicación web, una API, una app móvil o un SaaS con varios roles;
• es el primer pentest del producto;
• un cliente o un socio pide un informe de la prueba del producto.

Elige caja blanca si:

• por el sistema pasa dinero o controla el acceso;
• tienes criptografía propia o una lógica de permisos compleja;
• ya se hicieron pruebas de caja gris, los hallazgos están corregidos y necesitas ir más a fondo.

Si el pentest es nuevo para ti, empieza por qué es un pentest. Los formatos y el alcance están en la página de pentest.

Errores comunes

• Elegir caja negra porque «es más realista». Los días pagados se van en reconocimiento y las funciones tras el login quedan sin probar.
• Dar una sola cuenta. Con una cuenta no se puede comprobar si un cliente ve datos de otros ni si un gestor puede hacer acciones de administrador.
• Probar en un staging vacío. Sin datos no hay nada que «robar» y algunos hallazgos no aparecen.
• Entregar el código sin acceso al sistema en marcha. Los problemas de configuración y de interacción entre componentes solo aparecen en un entorno vivo.
• Ocultar problemas conocidos. El NCSC aconseja compartir con el equipo una evaluación de vulnerabilidades reciente si la tienes ^[6]. Así el pentester no pierde tiempo en lo que ya se sabe.
• Confundir «caja gris» con «pentest interno». Lo primero trata de lo que sabe el pentester; lo segundo, de desde dónde ataca.

Checklist: qué dar al pentester para una caja gris

• La lista de roles del sistema y dos cuentas de prueba para cada rol.
• Datos de prueba en cada cuenta: pedidos, facturas, documentos.
• La descripción de la API: OpenAPI (Swagger), una colección de Postman o una lista de endpoints.
• Las direcciones del entorno y una decisión por escrito: staging o producción.
• Una descripción breve de la arquitectura: qué servicios hay, dónde se guardan los datos, qué integraciones de terceros.
• Las builds de las apps móviles, si están en el alcance.
• La lista de acciones prohibidas y de sistemas fuera del alcance.
• Un contacto localizable durante la prueba y una forma de pararla.
• Los resultados de escaneos y pentests anteriores.

Descargar la lista de preparación (PDF)PDF · A4

FAQ

¿Qué tipo de pentest es el mejor?

Para la mayoría de las aplicaciones web, APIs y apps móviles funciona mejor la caja gris: el pentester recibe cuentas y documentación y dedica el tiempo a buscar vulnerabilidades. La caja negra se elige para el perímetro externo, y la caja blanca para el código crítico.

¿La caja negra es más realista que la caja gris?

Se parece más a un atacante externo, pero uno de verdad no tiene un límite de pocos días y a menudo consigue una cuenta con el registro o con phishing. La caja gris empieza desde ese punto y cubre más en el mismo tiempo.

¿Es seguro darle el código fuente al pentester?

Sí, si el acceso está limitado por el alcance y un NDA, y el código se borra al terminar el proyecto. A menudo basta con compartir los módulos críticos y no todo el repositorio.

¿Cuántas cuentas de prueba necesita una caja gris?

Normalmente dos por rol. Dos cuentas del mismo rol muestran si un usuario puede ver datos ajenos, y las cuentas de roles distintos muestran si se pueden escalar privilegios.

¿Se pueden combinar varios formatos en un mismo proyecto?

Sí, y es un esquema habitual. Por ejemplo, la aplicación se prueba como caja gris, el módulo de pagos como caja blanca y el perímetro externo como caja negra.

Referencias

1. NIST CSRC Glossary: Black Box Testing csrc.nist.gov
2. NIST CSRC Glossary: Gray Box Testing csrc.nist.gov
3. NIST CSRC Glossary: White Box Testing csrc.nist.gov
4. NIST SP 800-115: Technical Guide to Information Security Testing and Assessment csrc.nist.gov
5. OWASP Web Security Testing Guide v4.2: Introduction wstg.owasp.org
6. NCSC: Penetration testing ncsc.gov.uk