Meilleures pratiques pour un examen de sécurité dans un environnement de production

Exécuter un examen de sécurité dans un environnement de production est risqué ; cependant, il peut s'avérer nécessaire d'exécuter l'examen d'un environnement de production, par exemple pour respecter des exigences d'audit, pour détecter un piratage du site ou pour valider le fait que le processus SDLC (Software Development Life Cycle) est utilisé pour l'intégration des examens de sécurité.

Quelles que soient vos raisons, il est toujours préférable de commencer l'examen sur un environnement de préproduction puis de passer à l'environnement de production. Grâce à cette approche, les tests de sécurité représentent moins de risques pour les serveurs.

Learn more about known security risks when scanning a production site :
  • Le plus grave : l'examen peut mettre en panne le serveur ou l'application.
  • Le moins grave : l'examen renvoie la même requête au serveur sous de nombreuses variantes (environ 40 par paramètre). Certaines de ces requêtes seront rejetées par le serveur, mais un grand nombre passeront et seront traitées par l'application, ce qui peut générer les actions suivantes :
    • Ajouter ou changer des enregistrements dans la base de données.
    • Effectuer des transactions, telles qu'un achat, que l'application a été conçue pour exécuter.
    • Inondation d'e-mails. Si un formulaire envoie un e-mail à une liste de diffusion ou à une personne, les destinataires peuvent en recevoir des centaines.
    • Dégradation du site. Si le site a une page de forum, l'examen peut publier de nombreuses entrées dans ce forum, y compris certaines avec des fenêtres en incrustation contenant du script intersite.
    • Modification complète du site. Si le site autorise les changements, par exemple avec les boutons créer, éditer et supprimer, des requêtes normales ainsi que de nombreuses variantes seront soumises.
    • Initiate®Envoi de requêtes aux services du fournisseur. Ces requêtes peuvent inonder (spam) les services, exécuter des transactions et entraîner des coûts imprévus.
    • Alerter votre équipe IDS/IPS (systèmes de détection/prévention d'intrusion). Les tests vont déclencher les systèmes IDS/IPS avec des milliers de signatures. Les tests ne sont pas de véritables attaques et ne sont pas destinés à endommager vos applications. Cependant, l'équipe IDS/IPS n'en est pas informée et va réagir en conséquence.
    • Les systèmes IDS et IPS vont considérer les tests comme une attaque.

Les meilleures pratiques qui suivent ont pour but de mettre en oeuvre un examen de sécurité dans un environnement de production, avec le moins de risque possible et les meilleurs résultats possibles.

Utilisez un compte utilisateur de test

Utilisez un compte de test afin d'assurer un suivi et de vérifier que les services ne sont pas réellement commandés. Ce compte peut en outre être réinitialisé en cas de corruption. Pour les administrateurs, un compte de test simplifie par ailleurs le nettoyage du site après le test. Prenez en compte les facteurs suivants pour les comptes de test :

  • Il doit uniquement avoir accès aux enregistrements de test dans la base de données, afin que les enregistrements modifiés puissent être restaurés.
  • Supprimez les nouveaux enregistrements créés par le compte de test.
  • Ignorez les ordres d'achat ou autres transactions provenant du compte de test.
  • Si le site comporte des forums, le compte de test doit uniquement accéder à des forums de test. Les clients véritables ne doivent pas voir les tests pendant la phase de tests. Voir, par exemple, une fenêtre en incrustation contenant du script intersite pourrait être inquiétant.
  • Utilisez plus d'un compte de test si le site utilise différents privilèges pour différents comptes. L'utilisation de plusieurs comptes de test assure un test plus complet de l'application.

Acceptation des utilisateurs et tests de performances

N'exécutez pas de tests de sécurité en production tant que l'application n'a pas été configurée en production pour gérer les procédures normales d'acceptation utilisateur et les tests de performances. Si l'application ne peut pas gérer ce type de tests, elle ne pourra pas gérer les requêtes transformées envoyées par le travail d'examen.

Obtenez l'approbation des responsables

L'examen unilatéral d'une application sans consulter le responsable de l'entreprise et l'équipe de développement et obtenir leur accord, est presque toujours un désastre. Prévenez à l'avance toutes les parties concernées de la date à laquelle les tests doivent être exécutés et de la date à laquelle ils seront terminés.

Etablissez un moment approprié pour exécuter l'examen

Exécutez l'examen à un moment prédéfini qui n'interférera pas avec les heures de fonctionnement habituelles du site, par exemple la nuit.

N'omettez pas les tests invasifs

Ces tests ne sont pas exécutés par défaut, mais ils sont très importants pour un test complet ; par exemple des vers Internet peuvent se trouver dans les dépassements de tampon. Tous les tests, invasifs ou non, sont susceptibles de provoquer un arrêt du site.

Evitez l'inondation d'e-mails

Identifiez les pages qui utilisent la notification par e-mail et excluez-les des examens. Les notifications par e-mail génèrent un grand nombre de requêtes et peuvent surcharger un serveur d'e-mail. Il peut être difficile d'identifier ces pages, cependant, voici plusieurs techniques utilisables :

  • Testez les pages en assurance qualité et excluez-les en production. En assurance qualité, changez l'adresse e-mail en une adresse factice.
  • En production, testez uniquement un serveur Web et empêchez-le de se connecter au serveur SMTP pendant le test, ou ayez un script qui remplace l'adresse e-mail avant le test et la restaure après le test.
  • Configurez l'examen pour placer une valeur unique dans l'une des zones de l'e-mail, ce qui permet au destinataire d'exécuter une recherche pour les supprimer tous. Utilisez le Remplissage automatique de formulaires pour exécuter cette fonction.

Développez et testez les scripts de nettoyage à l'avance.

Après exécution des examens de production, utilisez les scripts ou les programmes de nettoyage pour éliminer les données de test créées par les examens.

Identifiez les paramètres de session et les jetons

Identifiez les paramètres de session et les jetons qui invalideraient la session. Vous obtenez généralement ces informations auprès des propriétaires de l'application. Ajoutez des paramètres de session dans la page Paramètres et cookies du travail d'examen.

Identifiez les routines d'invalidation de compte

Identifiez toutes les routines d'invalidation de compte. Ajoutez-les aux exclusions afin que l'examen les évite.

  • Si possible, désactivez l'invalidation de compte pour les échecs de saisie de mot de passe.
  • S'il n'est pas possible de désactiver l'invalidation de compte, examinez chaque page de connexion séparément en utilisant un compte de test et un mot de passe.

Envisagez des examens sans authentification

Examinez les pages accessibles à l'extérieur de l'application sans authentification, en utilisant un travail d'examen séparé. L'exécution d'un examen à partir de l'extérieur permet de trouver davantage de problèmes et vous aidera à comprendre qui a accès aux problèmes de sécurité trouvés.

Utilisez des examens interactifs pour identifier les zones sensibles

Créez un travail séparé pour les parties nécessitant une interaction, par exemple une page de changement de mot de passe, une page de paramètres administratifs ou une page de gestion utilisateur.

Désactivez les systèmes IDS/IPS

Les systèmes IDS/IPS peuvent bloquer les tests et masquer les problèmes qui seraient autrement exposés, il est donc préférable de les désactiver ou d'exécuter l'examen autour de ces systèmes. Au minimum, vous devez prévenir l'équipe IDS/IPS.

N'effectuez pas d'examen via un proxy

L'examen via un proxy est pris en charge, mais ce type d'examen peut masquer les problèmes. A titre d'exemple, les proxy HTTP peuvent fausser les messages d'erreur du serveur et masquer ainsi les problèmes de sécurité.