Pentest web sur notre site en prod — comment rédiger le plan de test pour éviter les coupures ?

Attention aux fonctions de remplissage auto de formulaires sur les scanners. S'ils se mettent à bombarder la newsletter ou le formulaire de contact, ils peuvent vous générer 20 000 faux mails en 10 minutes et faire blacklister votre serveur d'envoi. Excluez ces formulaires des scans automatiques.

Créez un compte utilisateur de test dédié avec un solde virtuel pour l'équipe d'audit. Ne les laissez surtout pas faire des tests de suppression ou de réservation de panier sur des articles en stock visibles par les vrais clients, sinon vous allez verrouiller vos stocks.

On a fait tester notre prod il y a deux ans : l'auditeur a envoyé une payload avec une commande de temporisation (sleep) en cherchant une SQL Injection. Le pool de connexions à la base est tombé à sec en 3 minutes et toute notre page de paiement a renvoyé des erreurs pendant 20 minutes. Avoir un devops en astreinte pendant les tests, c'est indispensable.

On a calé ça entre 02h00 et 06h00. Sur un site à 1 000 commandes/jour, le volume tombe à 15 commandes la nuit. S'il y a un plantage, l'impact sur le CA est quasi nul. Ne faites jamais de test en prod sur les heures de bureau.

Comment ils vont tester la partie passerelle de paiement ? Ils vont faire des micro-transactions réelles de quelques centimes sur le TPE en prod ou vous allez brancher une fausse passerelle ? Si ce n'est pas cadré au contrat, la compta va devenir folle.

mettez impérativement le numéro de télééphone d'un interlocuteur unique dans le plan de test mais bref dès qu'un truc cloche, le pentester doit couper ses outils sur un simple appel d'arrêt venant de ce numéro.

Ne pas réussir à faire un staging ISO avec la prod et se lancer dans un pentest aux allures de stress test directement en prod, c'est vraiment le goût du risque à la sauce de notre secteur. Faites au moins un backup complet une heure avant le test histoire de pas vous taper un scénario catastrophe le lendemain matin.

Le contrat de test à établir doit stipuler clairement les responsabilités des parties et prévoir que tout préjudice commercial découlant du non-respect par l'équipe de test du planning et des créneaux horaires approuvés engagera la responsabilité du prestataire.

Nous avons vécu presque la même chose l'année dernière. Avant de décider, regardez quelles données vous avez en main.

C'est confirmé par l'expérience.

Trois points à vérifier lors de cette opération. Le vrai problème n'est pas le chiffre, mais la base sur laquelle il est calculé.

Ce que tout le monde fait ne signifie pas que c'est la bonne chose. À votre place, j'irais par cette voie.

Je suis d'accord.

Trois avis différents sont sortis, ils se complètent tous. bon si vous obtenez trois réponses différentes sur un sujet, la question est mal posée.

Corrigez-moi si je me trompe.

Je suis intéressé.

Trois points à vérifier lors de cette opération. Si vous grondez les fausses alertes plus personne ne signalera rien.

C'est mon avis, je ne l'écris pas comme une vérité absolue.

Exactement, et ce n'est pas si connu que ça. Essayer de faire cela seul est la voie la plus coûteuse.

Nous avons vécu presque la même chose l'année dernière. Les solutions qui fonctionnent à petite échelle s'effondrent en grandissant, j'ai appris cela trop tard.

J'espère que cela vous sera utile.

J'ai travaillé longtemps sur ce sujet. Si le chemin de notification est long, la notification n'arrive pas ; une notification manquante signifie un événement détecté tardivement.

Je le note au cas où.

Merci d'avoir écrit cela, c'est exactement ça... Le fait que la sauvegarde soit accessible sur le même réseau et avec la même identité en fait une cible potentielle.

L'erreur commise du côté de plan de test pentest web est généralement réversible mais coûteuse. Si vous avez des questions écrivez-moi je répondrai au mieux.