Vamos a contratar un pentest para una aplicación web, pero queremos prepararnos antes: ¿hay alguna lista de verificación propia que podamos aplicar?

El año pasado pagamos 5.000 libras por un test similar en un B2B. Al no prepararnos, 14 de los 22 hallazgos eran cabeceras HTTP faltantes y respuestas por defecto del servidor. Nos dolió mucho ver que al menos 1.500 libras del auditor se fueron en reportar tonterías.

Lo más crítico es la estabilidad del entorno. Creen un servidor de pruebas dedicado con una copia anonimizada de producción, nunca prueben en vivo. Así la operación no se cae si el auditor hace pruebas que corrompan la BD o saturen colas. Y congelen el código (no hagan deploys) mientras dure el test.

Revisen validación de entradas y cifrado. Verifiquen el escape de caracteres especiales en formularios y parámetros URL. Asegúrense de que los datos de entrada se filtren bien al escribir en la BD y que los tokens de sesión se invaliden en el servidor al cerrar sesión.

No simplifiquen demasiado el entorno por querer dejar todo perfecto. A veces los devs apagan el firewall o desactivan capas de seguridad para "facilitar las pruebas". Luego el sistema sale impecable en la auditoría pero explota en producción. El entorno de pruebas debe ser un espejo fiel de producción.

Entreguen dos cuentas válidas de dos roles distintos: dos usuarios normales y dos administradores. Añadan también una cuenta demo con permisos muy restringidos. Así podrán probar escalada de privilegios horizontal y vertical desde la primera hora sin trabas.

¿El acuerdo es caja blanca (white-box) o caja negra (black-box)? Si van a compartir código fuente y esquemas de API completar la documentación debe ser la prioridad. Si no le darán acceso al código, el enfoque debe estar 100% en los endpoints expuestos.

Excelente enfoque. Hacer esta preparación interna sube muchísimo la concienciación de seguridad del equipo. Si hacen un taller interno de medio día revisando los puntos clave de OWASP directamente en el código le sacarán el máximo provecho al pentest.

pongan si o si la ip en la lista blanca del firewall y pues en nuestro pentest el auditor quedo bloqueado el primer dia y perdimos medio dia mandando mails pa q abrieran la ip plata tirada a la basura.

Estoy de acuerdo.

A mí me pasó justo al revés, por eso escribo. Las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde.

Cuanto más difícil sea revertir una decisión, más despacio debéis tomarla. Comprobado por experiencia.

Si vas por ahí, resuelve esto desde el principio. Ningún proceso mejora si no se registran datos, porque no sabes qué tienes que arreglar.

Esta es mi opinión, no lo escribo como una verdad absoluta.

Permíteme resumir lo que se ha dicho hasta ahora. Un informe de escaneo automático no es lo mismo que una prueba de penetración.

Ánimo.

Este hilo es para archivar.

A nosotros nos pasó esto... Si no lo pones por escrito desde el principio luego surgen discusiones.

Los entornos de prueba olvidados son una puerta de entrada más frecuente que el sistema en producción. Si escribís el resultado aquí, también servirá de ayuda a otros.

Pienso diferente. Si decidimos sin medir, siempre acabamos en el mismo punto.

Una copia de seguridad no probada no es una copia de seguridad. Si tenéis dudas, escribid, os responderé en la medida de lo posible.

No tengo ninguna experiencia en test de penetracion aplicacion web, por eso pregunto. Que la copia de seguridad sea accesible en la misma red y con la misma identidad la convierte en parte del objetivo.

Si tenéis dudas escribid os responderé en la medida de lo posible.

Tema muy oportuno.

Lo que voy a preguntar sonará un poco novato, perdonadme. La mayoría de los incidentes no empiezan por una vulnerabilidad, sino por una contraseña filtrada.