Pentest web en sitio en producción — ¿cómo redactar un plan de pruebas para evitar caídas?

Cuidado con la función de auto-completado de formularios de los escáneres automáticos. Si empiezan a probar el formulario de contacto o suscripción, te pueden meter 20 mil e-mails falsos en cola en 10 minutos y mandar tu servidor de correo saliente a una lista negra. Excluyan esos formularios del escaneo.

Denle al equipo de auditoría un usuario de prueba dedicado y asígnenle saldo. Ni se les ocurra dejar que prueben borrar o reservar stock en productos reales visibles para los clientes, porque después se bloquea el inventario.

Hace dos años probamos en producción y el auditor lanzó una consulta con comando de sleep buscando SQL Injection. El pool de conexiones de la base de datos se agotó en 3 minutos y toda la pantalla de pago tiró error durante 20 minutos. Es obligatorio tener un devops de guardia.

Nosotros lo hicimos de 02:00 a 06:00 de la mañana. En un sitio de 1.000 pedidos diarios, de noche baja como a 15. Si se llega a bloquear algo, el costo de perder clientes es casi cero; de ninguna manera hagan pruebas en producción en horario laboral.

¿Cómo van a probar la parte de la pasarela de pagos? ¿Van a cobrar centavos en un POS real o van a armar un gateway de prueba? Si esto no queda claro en el contrato, el área de finanzas se va a volver loca.

pongan sí o sí un solo número de teléfono autorizado en el plan de pruebas. en cuanto se note algo raro, la persona que hace el pentest tiene que apagar las herramientas apenas reciba la orden de parar desde ese número.

No poder hacer el entorno de staging idéntico al de producción y ponerse a hacer pentest en vivo a modo de prueba de estrés es una búsqueda de aventuras genial muy típica de nuestro sector. Por lo menos saquen un backup completo una hora antes del test para no vivir un escenario de desastre a la mañana siguiente.

En el contrato de prueba a elaborar se deben especificar claramente las responsabilidades de las partes, estipulando que la empresa contratista será responsable de las pérdidas comerciales que surjan si el equipo de pruebas se sale del plan y los horarios aprobados.

El año pasado nos pasó casi exactamente lo mismo. Antes de decidir, mirad qué datos tenéis en la mano.

Comprobado por experiencia.

Hay tres cosas que revisar al hacer esto. Lo importante no es la cifra, sino en qué se basa esa cifra.

Que todo el mundo haga algo no significa que sea lo correcto. Yo seguiría por ese camino.

Estoy de acuerdo.

Han surgido tres opiniones distintas todas se complementan. bueno si obtienes tres respuestas distintas sobre un tema, la pregunta está mal formulada.

Corrijanme si me equivoco.

Estoy siguiendo esto.

Hay tres cosas que revisar al hacer esto. Si regañas las falsas alarmas nadie volverá a reportar.

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

Exacto, y encima no es tan conocido. Intentar hacerlo solo es la vía más cara.

El año pasado nos pasó casi exactamente lo mismo. Las soluciones que funcionan a pequeña escala se rompen al crecer, aprendí esto tarde.

Espero que le sea útil.

Llevé mucho tiempo con este asunto. Si el camino de la notificación es largo, la notificación no llega; una notificación que no llega significa un incidente detectado tarde.

Lo dejo como nota, por si sirve.

Gracias por escribir esto es lo correcto. en fin que la copia de seguridad sea accesible en la misma red y con la misma identidad la convierte en parte del objetivo.

El error cometido por plan de pruebas pentest web suele ser reversible, pero caro. Si tenéis dudas escribid os responderé en la medida de lo posible.