Il est impossible qu'un pentester puisse garantir à 100% que les données ne seront pas modifiées ou supprimées, de la même manière qu'il ne peut pas garantir que la disponibilité du système ne sera pas affectée (j'ai renversé des systèmes avec un port scan ou un seul caractère). comme vous le dites, un robot d'exploration peut supprimer des données d'un système s'il a été mal configuré.

Je dirais que ce qui devrait être dit est quelque chose comme "tout sera pris pour s'assurer que les tests n'affecte pas négativement les systèmes examinés et aucune tentative délibérée ne sera faite pour modifier ou supprimer les données de production ou pour affecter négativement la disponibilité des systèmes concernés. Cependant, avec tous les tests de sécurité, il existe un risque que les systèmes soient affectés et le client doit veiller à ce que des sauvegardes de toutes les données et de tous les systèmes soient en place avant le début de l'examen "

Un pentester qui prétend qu'il ne modifiera jamais les données de production est soit un sale menteur , soit se pense beaucoup plus compétent qu'il ne l'est en réalité, soit fortement a l'intention de ne rien faire du tout (c'est le seul moyen infaillible de ne jamais rien casser). Dans tous les cas, vous ne voulez pas travailler avec ce type.

Un client potentiel qui croit que les pentesters qualifiés n'endommageront jamais les systèmes testés, et qui refuse de travailler avec des pentesters à moins de promettre exactement cela, est un client qui 1. vit dans le pays des rêves des licornes féeriques, et 2. est presque assuré de ne jamais faire affaire qu'avec de sales menteurs. Il est dans une certaine désillusion à un moment donné, probablement d'une manière assez spectaculaire.

C'est un impératif moral et aussi une auto-protection de base pentesters d'inclure des clauses de rupture éventuelle dans leurs contrats. Le risque de dommages collatéraux est réel, même si le pentester est très bon dans ce qu'il fait (car les dommages ne viennent pas de la qualité du pentester mais de la mauvaise conception du système testé et mis en œuvre ). Un pentester pourrait être poursuivi pour ne pas avoir averti le client.

Un client qui refuse un contrat avec une telle clause porte un autre nom: "trouble". Il est généralement préférable d'ignorer complètement ces clients.

Attention: je ne suis pas un pentester professionnel. Et je travaille dans un logiciel de sauvegarde.

Un pentester qualifié et professionnel peut-il toujours garantir qu'aucune donnée ne sera supprimée ou modifiée en production lors d'un pentest?

Je dirais non, il n'y a aucune garantie absolue que quelque chose ne sera pas accidentellement supprimé lorsque vous essayez de casser des choses. Cependant, cela dit, un pentester devrait généralement essayer d'exploiter les systèmes d'une manière qui n'implique pas la suppression de données. Par exemple, alors que l'instruction SQL préférée de tout le monde est:

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

Une approche plus responsable consisterait simplement à lister toutes les données:

  sélectionnez * parmi les utilisateurs où userid = '2' OU 1 = 1;  

En général, j'imagine que la plupart des testeurs de stylos ont développé une série d'exploits de type non destructif comme ce dernier.

L'injection de Javascript sous ses différentes formes peut utilisez un simple code de preuve de concept tel que alert ("vous a exploité"); plutôt qu'un véritable code d'exploitation.

Un pentest peut-il vraiment être fait si l'équipe du pentest a la limitation que les données ne peuvent pas être créées ni modifiées?

Je dirais non. Comment montriez-vous une preuve de concept de XSS stocké sans pouvoir stocker votre XSS dans la base de données? Cela créera invariablement de nouvelles données.

Il existe de nombreux exemples où un exploit nécessite l'écriture de données, même si ce n'est que temporairement.

L'entreprise de pentesting devrait-elle toujours inclure la clause de non-responsabilité au cas où?

Encore une fois, j'étends mes connaissances personnelles ici, mais je vais dire oui.

Cela revient à tout l'intérêt d'embaucher une entreprise de test de stylos en premier lieu, cependant. Le but d'un test de stylo est d'identifier les risques qui pourraient nécessiter une évaluation et de les corriger avant que les méchants ne les trouvent.

J'espère aussi que tout bon pentester demanderait, et toute bonne entreprise aurait pensé, une reprise après sinistre à une certaine échelle. Vous devriez sûrement avoir une sauvegarde d'une certaine forme sur vos systèmes afin de pouvoir restaurer si nécessaire. Vous en avez besoin non seulement au cas où le pentest détruirait vos données, mais au cas où vous seriez vraiment violé par les méchants, auquel cas vous voudrez peut-être une sauvegarde non contaminée sur laquelle revenir.

Je lance des tests d'intrusion assez régulièrement sur mes sites.

La première fois que j'en ai exécuté un, j'ai mis le site à l'arrêt et inondé leur serveur de messagerie de spam.

J'ai alors tweeked quelques formulaires, pour se débarrasser du spam et cela a permis d'identifier et de réparer tous les autres trous connus, sans arrêter le serveur.

J'ai été franchement étonné de la sournoiserie des exploiteurs , J'ai dû boucher des trous que je n'avais pas envisagés.

Mais le problème, c'est qu'avant d'exécuter les tests, je pensais que mes sites étaient sécurisés. J'avais suivi les meilleures pratiques, dans la mesure où elles allaient, pour la conception de sites Web, mais il y avait encore des problèmes.

Maintenant, avec le recul, j'apprécie que les tests peuvent affecter mon site de production.

Je prévois donc à l'avance.

Je m'assure que tout est d'abord sauvegardé.

Si le site est vraiment, vraiment critique, je créerai un clone complet, alors testez d'abord ce clone.

J'ai appris par expérience que si vous créez le clone, créez-le sur un serveur différent. Sinon, lorsque le clone s'arrête, le serveur affectera toujours votre environnement de production.

Mais je continue à faire mes tests. Comment pensez-vous que les pirates ont accès aux sites? Ils exécutent vraisemblablement des tests comme ceux-ci eux-mêmes, de manière non autorisée. Ainsi, tant que votre site n'est pas protégé, il sera toujours vulnérable. Il vaut bien mieux faire les tests en premier, avec les précautions (sauvegarde, etc.) en place, plutôt que de ramasser les pièces quand on s'y attend le moins.

Donc, oui, c'est acceptable, mais c'est est également prévisible et doit être gérée en conséquence.

La réponse à votre titre est "Oui", et le client doit le savoir!

Cette clause de non-responsabilité n'est pas un cas de CYA, c'est plutôt des informations vitales dont le client a besoin pour se préparer le pentest. Je ne suis pas un testeur de stylo, mais l'OMI cela ne devrait pas être enterré sur la dernière page des petits caractères, mais devrait être sur la page 1 du contrat, au centre et au centre et dans une grande police en gras. L'entreprise cliente doit se préparer à ce que les choses tournent mal - des sauvegardes doivent être effectuées, des plans de récupération créés et mis en place, etc. Laisser le client croire qu'un test du stylet est sans risque est irresponsable. Vous essayez par définition de déclencher un comportement incorrect, sans aucun contrôle sur la portée ou l'étendue de ce comportement brisé.

Les réponses aux 3 questions dans le corps de votre message sont: (1) non, vous ne peut faire aucune garantie sur le code des autres (2) une forme limitée de test de stylet pourrait être effectuée sans modifier ou créer INTENTIONNELLEMENT des données (si vous excluez toute journalisation que l'application peut faire) mais les résultats ne seraient pas complets, et enfin ( 3) vous devez TOUJOURS inclure cette clause de non-responsabilité - autant pour le bénéfice du client que pour le vôtre.

Le testeur recherche essentiellement une faille à exploiter et ne peut en aucun cas garantir qu'il ne trouvera pas de faille cela fait des dégâts. Considérez une clause de non-responsabilité de logiciel typique pour quelque chose qui n'est PAS destiné à rencontrer ou créer des failles, puis considérez que vous n'avez probablement pas écrit le code que vous testez ...

Vous ne pouvez probablement vous assurer que sous certaines conditions. De toute évidence, Pentest est un compromis entre de nombreux facteurs, certains facteurs sont directement antagonistes à la disponibilité du système et l'un d'entre eux est la profondeur de votre analyse. Certains pourraient soutenir qu'un pentest sans exploitation n'est pas un pentest.

Dans le passé, j'ai dû tester certains systèmes SCADA qui sont assez connus pour leur fragilité et je peux vous assurer qu'il est possible de régler la plupart des outils pour être assez doux. Par exemple, la désactivation de l'empreinte digitale NMAP et le délai croissant entre les paquets ont beaucoup aidé.

Cependant, pour répondre personnellement à votre question, je n'accepterai JAMAIS de mettre une clause pour garantir cela à un de mes clients. Je vais lui donner ma parole, mais sur le plan commercial, vous ne pouvez pas être responsable si leur candidature se rompt d'elle-même pendant votre pentest.

"Un pentester qualifié et professionnel peut-il toujours garantir qu'aucune donnée ne sera supprimée ou modifiée en production pendant un pentest?"

Non.

"Un pentest peut-il vraiment être fait si l'équipe du pentest a la limitation que les données ne peuvent pas être créées ni modifiées?"

Je ne pense pas. .

"La société de test doit-elle toujours inclure la clause de non-responsabilité au cas où?"

Un accord interne sera très différent de celui d'un tiers accord. Je ne connais aucune entreprise de test de stylo qui n'ait pas de limitation d'assurance responsabilité civile, entre autres protections ...

Les tests de pénétration doivent suivre une méthodologie où les tests qui peuvent causer des dommages ne sont effectués que dans des scénarios hors production, comme un environnement de test ou de laboratoire.

Le vrai problème n'est pas la suppression ou la modification des données car les testeurs peuvent laisser ces cas de test à des systèmes hors production. Le vrai problème est de laisser de nouvelles données, telles que des journaux d'erreurs ou des fichiers erronés superflus qui révèlent des informations confidentielles, ou même l'existence du pentest lui-même, y compris les données côté client du testeur de pénétration.

Un autre problème La révélation d’autres données de clientèle, d’e-mails professionnels ou de signets de navigateur lors de démonstrations ou de screencasts est courante dans les tests de pénétration.