Pentesting de aplicaciones web

De una a tres semanas de pruebas, según el alcance. El resto del proceso es corto: media hora de Kick-Off, un día para escribir el plan de auditoría y de uno a tres días para el informe técnico. Las fechas y las ventanas de prueba se acuerdan contigo antes de empezar y quedan escritas en ese plan.

Las de más arriba en esta ficha. Van escritas en el plan de auditoría que firmas antes de que empecemos. La herramienta da la cobertura y la persona da la profundidad: un escáner recorre en una tarde lo que ningún auditor recorrería, y no entiende ni una sola de las reglas de tu negocio.

Sí, con las salvaguardas del Kick-Off. Trabajamos con explotación controlada y en la ventana que tú elijas, y no comprometemos la disponibilidad sin autorización expresa por escrito. Si aparece algo crítico no esperamos al informe: te avisamos en el momento, por el canal que hayamos pactado.

Sí. Cuando hayas aplicado las correcciones volvemos a probar cada hallazgo, uno a uno, para verificar que queda cerrado de verdad. Tienes hasta seis meses para pedirlo y no se factura aparte. El retest cierra con un informe nuevo, que es el documento con el que responder ante un cliente o ante un auditor.

Una vez al año. Y siempre que cambie de forma relevante lo que entra en el alcance: un despliegue grande, una migración o una integración nueva. Varias normas lo piden ya de forma explícita, y el requisito 11.4 de PCI DSS marca directamente una periodicidad anual.

Sí, y cuantos más roles nos des, mejor. Con un usuario de cada rol podemos probar el control de acceso horizontal y vertical, que es donde aparecen la mayoría de los fallos graves de una aplicación web. Los pides tú en el Kick-Off. Si no es posible auditamos en caja negra, y lo dejamos escrito en el informe: el alcance real será menor.

Sobre el más parecido a producción. Preproducción vale si corre el mismo código y la misma configuración; si es una versión de hace tres meses, los resultados no sirven de nada. Cuando solo existe producción, trabajamos en la ventana que nos des y sin pruebas que puedan afectar a la disponibilidad.

Entra la que consume el frontal. Un atacante no distingue entre las dos capas. Si además publicas una API para terceros, con su propia autenticación y sus propios clientes, eso es un alcance aparte: se audita como pentesting de APIs y contra el OWASP API Top 10, que ordena las pruebas de otra manera.

El WAF sube el listón. No arregla el fallo que hay detrás: un IDOR, un permiso mal puesto o una lógica de negocio rota lo atraviesan sin activar ninguna firma, porque son peticiones perfectamente válidas. Auditamos con el WAF puesto y, si nos lo permites, también sin él.