Cuando hace un pentest, ¿cuál es su recomendación al cliente sobre cómo manejar / interpretar el informe?
Lo que veo con frecuencia es que los problemas identificados, especialmente los relacionados con el software de desarrollo propio, no se solucionan correctamente. El ejemplo más sencillo es el XSS, que está "remediado" por s /// (reemplaza exactamente la Cadena XSS del informe con nada).
Esta solución, obviamente, no es buena; por un lado, porque el XSS todavía existe y por otro lado porque este error es una clara indicación de que el concepto de manejo de la entrada del usuario no es seguro de ninguna manera. Desde mi punto de vista, esto significa que otras vulnerabilidades de XSS están presentes aunque no las encontré. Asumir que un probador encuentra todas las vulnerabilidades es, en mi opinión, poco realista.
¿Cómo consigo que el cliente piense así? Por ejemplo, quiero que el cliente diga "¡Oh, has encontrado un XSS! Probablemente necesitemos alguna adaptación de tecnología / proceso / arquitectura ... para deshacernos de estas cosas tanto como sea posible. Tal vez utilicemos un marco web e introducamos Solución SAST ".
Aprendí que los bloques de texto de remediación genéricos al final de cada informe no son suficientes en absoluto. Lo que ha demostrado ser bastante efectivo son los talleres de remediación: básicamente se analizan los resultados en un taller de 2 a 3 días y luego se respaldan los desarrolladores durante la implementación. Por supuesto, solo una pequeña cantidad de clientes están dispuestos a pagar por esto (y realmente no tengo los recursos).