No hay forma de que un pentester pueda asegurar al 100% que los datos no se modifiquen o eliminen, de la misma manera que no aseguran que la disponibilidad del sistema no se vea afectada (he golpeado los sistemas con un puerto escanear o un solo 'carácter'). como usted dice, un rastreador web puede eliminar datos de un sistema si está mal configurado.

Diría que lo que se debe decir es algo como "se tomarán todas las precauciones necesarias para garantizar que las pruebas no afecten negativamente a los sistemas bajo revisión y no se harán intentos deliberados de modificar o eliminar los datos de producción o de manera negativa. afecta la disponibilidad de los sistemas dentro del alcance. Sin embargo, con todas las pruebas de seguridad, existe el riesgo de que los sistemas se vean afectados y el cliente debe asegurarse de que se realicen copias de seguridad de todos los datos y sistemas antes del inicio de la revisión "

Un pentester que afirma que nunca nunca alterará los datos de producción es un mentiroso asqueroso , o se cree que es mucho más competente de lo que realmente es, o bien tiene la intención de no hacer nada (esa es la única manera segura de no romper nada). En cualquier caso, no quieres trabajar con ese tipo.

Un cliente potencial que cree que los pentesters expertos nunca dañarán los sistemas probados, y que se niega a trabajar con pentesters a menos que prometan exactamente eso, es un cliente que 1. vive en el país de los sueños del unicornio de las hadas, y 2. está casi garantizado para hacer negocios solo con mentirosos inmundos. En algún momento se encuentra con cierta desilusión, probablemente de una manera bastante espectacular.

Es un imperativo moral y también autoprotección básica para que los pentesters incluyan cláusulas sobre posibles roturas en sus contratos. El riesgo de daño colateral es real, incluso si el pentester es muy bueno en lo que hace (porque el daño no proviene de lo bueno que es el pentester sino de lo malo que fue diseñado el sistema probado e implementado ). Se podría demandar a un pentester por no haber avisado al cliente.

Un cliente que rechaza un contrato con dicha cláusula tiene otro nombre: "problema". Por lo general, es mejor omitir estos clientes por completo.

Advertencia: no soy un pentester profesional. Y trabajo en software de copia de seguridad.

  

¿Puede un pentestro cualificado y profesional garantizar siempre que no se eliminarán o modificarán los datos en la producción durante un pentest?

Yo diría que no, no hay garantías absolutas de que algo no se elimine accidentalmente cuando se intenta romper cosas. Sin embargo, dicho esto, un pentestro generalmente debería tratar de explotar los sistemas de una manera que no implique la eliminación de datos. Por ejemplo, mientras que la declaración SQL favorita de todos es:

select * from users where userid='dave'; DROP ALL TABLES;

Un enfoque más responsable sería simplemente listar todos los datos:

select * from users where userid='2' OR 1=1;

En general, me imagino que la mayoría de los probadores de lápiz han desarrollado una serie de proezas de la variedad no destructiva como la última.

La inyección de Javascript en sus diversas formas puede utilizar un código de prueba de concepto simple como alert("exploited you"); en lugar de un código de explotación genuino.

  

¿Se puede hacer un pentest realmente si el equipo de pentest tiene la limitación de que los datos no se pueden crear ni modificar?

Yo diría que no. ¿Cómo mostraría una prueba de concepto de XSS almacenado sin poder almacenar su XSS en la base de datos? Esto invariablemente va a crear nuevos datos.

Hay numerosos ejemplos en los que un exploit requiere escribir datos, aunque solo sea temporalmente.

  

¿Debería la compañía de pentesting incluir siempre la cláusula de exención de responsabilidad por si acaso?

Una vez más, estoy extendiendo mi conocimiento personal aquí, pero voy a decir que sí.

Sin embargo, esto se remonta al punto de contratación de una empresa de pruebas de lápiz en primer lugar. El objetivo de una prueba de lápiz es identificar los riesgos que podrían ser necesarios para evaluarlos y corregirlos antes de que los malos los encuentren.

También desearía que cualquier buen pentester pediría, y cualquier buen negocio hubiera pensado, la recuperación de desastres en alguna escala. Seguramente debería tener una copia de seguridad de alguna forma en sus sistemas para que pueda restaurar según sea necesario. Necesitas esto no solo en caso de que el Pentest destruya tus datos, sino en el caso de que realmente estés maltratado por los malos, en cuyo caso es posible que desees una copia de seguridad no contaminada para volver a.

Realizo pruebas de penetración con bastante frecuencia en mis sitios.

La primera vez que ejecuté una, detuve el sitio e inundé su servidor de correo con spam.

Luego ajusté algunas formas para deshacerme del spam y me permitió identificar y reparar todos los demás agujeros conocidos, sin moler el servidor.

Francamente me sorprendió la perversidad de los explotadores, tuve que tapar agujeros que no había considerado.

Pero antes de ejecutar las pruebas, pensé que mis sitios eran seguros. Había seguido las mejores prácticas, hasta el momento, para el diseño de sitios web, pero todavía había problemas.

Ahora, con el beneficio de la retrospectiva, aprecio que las pruebas puedan afectar mi sitio de producción.

Así que planeo con anticipación.

Me aseguro de que todo esté respaldado primero.

Si el sitio es realmente crítico, crearé un clon completo y luego probaré ese clon primero.

Por experiencia, he aprendido que si creas el clon, créalo en un servidor diferente. De lo contrario, cuando el clon se detenga, el servidor seguirá afectando su entorno de producción.

Pero todavía llevo a cabo mis pruebas. ¿Cómo crees que los hackers obtienen acceso a los sitios? Es de suponer que realizan pruebas como estas, de forma no autorizada. Entonces, hasta que su sitio esté protegido, siempre será vulnerable. Es mucho mejor hacer las pruebas primero, con las precauciones (copia de seguridad, etc.) establecidas, que tener que recoger las piezas cuando menos lo espere.

Entonces, sí, es aceptable, pero también es predecible, y debe gestionarse en consecuencia.

La respuesta a tu título es "Sí", ¡y el cliente necesita saber esto!

Este descargo de responsabilidad no es un caso de CYA, sino que es información vital que el cliente necesita para prepararse para el Pentest. No soy un probador de bolígrafos, pero, en mi opinión, esto no debería estar oculto en la última página en la letra pequeña, pero debería estar en la página 1 del contrato, al frente y en el centro y en letra grande y en negrita. La empresa cliente debe prepararse para que las cosas salgan mal: es necesario realizar copias de seguridad, crear y poner en marcha planes de recuperación, etc. Dejar que el cliente crea que una prueba de la pluma es libre de riesgos es irresponsable. Por definición, intentas desencadenar un comportamiento incorrecto, sin control sobre la extensión o el alcance de ese comportamiento roto.

Las respuestas a las 3 preguntas en el cuerpo de su publicación son: (1) no, no puede garantizar el código de otros (2) se puede realizar una forma limitada de prueba de la pluma sin modificar INTENCIONAMENTE la creación de datos (si excluye cualquier registro que pueda hacer la aplicación) pero los resultados no estarían completos, y finalmente (3) SIEMPRE debe incluir este descargo de responsabilidad, tanto para el beneficio de los clientes como para el suyo.

El probador básicamente está buscando una falla para explotar y no puede garantizar de ninguna manera que no encontrará una falla que cause daño. Considere un descargo de responsabilidad del software típico para algo que NO está destinado a encontrar o crear fallas, y luego considere que probablemente no escribiste el código que estás probando ...

Probablemente puede asegurar que solo bajo ciertas condiciones. Obviamente, Pentest es una compensación entre muchos factores, algunos factores son directamente antagonistas de la disponibilidad del sistema y uno de ellos es la profundidad de su análisis. Algunas personas podrían argumentar que un pentest sin explotación no es un pentest.

En el pasado tuve que probar algunos sistemas SCADA que son muy famosos por su fragilidad y les puedo asegurar que es posible ajustar la mayoría de las herramientas para que sean lo suficientemente suaves. Por ejemplo, deshabilitar la huella digital de NMAP y aumentar la demora entre paquetes ayudó mucho.

Sin embargo, para responder a su pregunta, personalmente, NUNCA aceptaré poner una cláusula para garantizar eso a un cliente mío. Le daré mi palabra, pero desde el punto de vista empresarial, no puede ser responsable si su aplicación se rompe sola durante su Pentest.

  

"¿Puede un pentester calificado y profesional asegurar siempre que no haya datos?   será eliminado o modificado en producción durante un pentest? "

No.

  

"¿Se puede hacer un pentest si el equipo de pentest tiene la limitación?   esos datos no pueden ser creados ni modificados? "

No lo creo ...

  

"En caso de que la empresa de pentesting incluya siempre la cláusula de exención de responsabilidad   ¿por si acaso? "

Un acuerdo interno se verá muy diferente de un acuerdo de terceros. No conozco ninguna compañía de prueba de pluma que no tenga limitaciones de seguro de responsabilidad, entre otras protecciones ...

Las pruebas de penetración deben seguir una metodología en la que las pruebas que pueden causar daños solo se realicen en escenarios de no producción, como un entorno de laboratorio o de estadificación.

El problema real no es la eliminación o modificación de datos porque los evaluadores pueden dejar esos casos de prueba a sistemas que no sean de producción. El problema real es dejar datos nuevos, como registros de errores o archivos erróneos superfluos que revelan información confidencial, o incluso la existencia del propio Pentest, incluido el material de datos del lado del cliente del probador de penetración.

Otro problema que prevalece en las pruebas de penetración es la revelación de otros datos de la clientela, correo electrónico del trabajo o marcadores del navegador durante demostraciones o screencasts.