« Retour

30 Days of Security Testing – Partie 4/4 : Aller plus loin

Le principe

Notre série d’article sur le défi de Ministry of Testing30 Days of Security Testing, se termine aujourd’hui avec un article dans lequel sont regroupé les défis qui permettent d’enrichir sa connaissance générale des tests de sécurité (actualités, aspects sociologiques, mises en application).

  1. Compulser la documentation
  2. Apprendre les bonnes pratiques
  3. Découvrir les outils
  4. Aller plus loin

Les challenges

Défi 10 : Comprendre ce qu’est l'« ethical hacking » & Défi 30 : Découvrir la différence entre les hackers black hat, white hat et grey hat

Pour rappel, en anglais « to hack » veut simplement dire « bidouiller », il n’y a pas de connotation négative en soi.

Alors que le hacker malveillant (ou black hat) tire profit des failles de sécurité à des fins personnelles, l’ethical hacker (ou white hat) les documente et propose des pistes afin de les solutionner. Il est en possession de toutes les autorisations nécessaires pour entrer dans le système à tester.

Comme vu précédemment, certaines entreprises embauchent des spécialistes en tests de sécurité (qui, par nature, sont des ethical hackers) afin de réaliser un audit. D’autres choisissent de récompenser les personnes qui leur rapportent bénévolement des failles de sécurité découvertes dans les limites de la légalité. Ces récompenses sont appelées « bounties ».

Si le hacker entre dans le système sans disposer des autorisations nécessaires, mais ne commet aucun acte malveillant, on parle de hacker « gray hat ». Des sites comme CVE Details (common vulnerabilities exposure) ou NVD (National Vulnerability Database) répertorient les failles de sécurité d’une multitude de produits.

L’imagerie populaire du hacker est déconcertante : nous serions tentés de croire que tous portent une capuche en permanence. En cause, une méconnaissance de l’activité de hacking, comme en témoigne cette interview d’un photographe de la banque d’images Shutterstock. Il serait pourtant utile que l’activité de hacking, de même que la sécurité informatique, soit mieux comprise, afin que chacun puisse mettre en oeuvre le nécessaire pour se protéger.

Défi 17 : Trouver une faille de sécurité récente

Lorsqu’une faille de sécurité est découverte dans un SI, volontairement ou non, le fait de la rapporter à l’organisation concernée sans exploiter la faille est appelé « disclosure ». Un acte bénévole dont il peut être risqué de parler, comme l'a montré en 2009 l'affaire Forever living products contre Zataz. Le fait de rendre une faille publique avant sa correction (chose que n'avait pas fait Zataz) est appelé « full disclosure ».

L’équipe Project Zero, qui regroupe sous l’égide de Google des spécialistes en sécurité informatique, a pour objectif de trouver des failles de sécurité « zero day », c’est-à-dire n’ayant jamais été exploitées. Leur ligne de conduite : informer immédiatement l’organisation responsable de l’application (disclosure), et ne procéder à une full disclosure qu’après que celle-ci a fourni un patch, ou au bout de 90 jours.

Le 25 novembre dernier, Google a informé Microsoft d’une faille de sécurité présente dans les navigateurs Internet Explorer et Edge. Malheureusement, Microsoft n’a pas été en mesure de fournir un patch dans les temps, et la faille est désormais publique et exploitable même dans la dernière version ! Voici son ticket d’anomalie.

Défi 20 : S’informer sur les attaques DOS/DDOS.

Une attaque DDOS (Distributed Denial Of Service) est une attaque visant à rendre indisponible un serveur. Son qualificatif « Distributed » est employé lorsque l’attaque provient de plusieurs machines différentes. Lorsque l’origine est une unique machine, on parle simplement d’attaque DOS.

On peut distinguer les attaques DDOS réseau et applicatives. Dans le premier cas, on sature la connexion réseau d’un serveur afin de le rendre incapable de répondre aux requêtes. Dans le second, après identification des actions de l’application qui demandent beaucoup de ressources (par exemple, des calculs impactant de nombreuses lignes en base de donnée), l’attaque consiste à les répéter jusqu’à saturation du serveur (source).

Un site web permet de visualiser sur une carte les récentes attaques DDOS.

Défi 23 : Quelles sont les 10 menaces de sécurité les plus courantes en 2016 ?

La liste des 10 failles de sécurité les plus courantes est éditée tous les trois ans par la fondation OWASP. La liste qui devait paraître en 2016 a été repoussée en 2017. L’équipe OWASP explique que le classement est resté sensiblement le même. Voici donc le classement de 2013.

Défi 26 : Comparer les tests de sécurité web et mobiles

Les tests à effectuer dépendent des menaces inhérentes à un système donné.

Certaines menaces sont propres aux applications web, comme les vulnérabilités liées aux cookies. Ces petits fichiers, stockés sur la machine cliente au cours de la navigation, qui contiennent des informations utiles : pages visitées, actions effectuées sur le site, mots de passe.

D’autres sont spécifiques aux applications mobiles, qui demandent des permissions susceptibles de compromettre les informations personnelles de l’utilisateur.

Mais les frontières des menaces tendent à se brouiller, notamment avec l’essor de frameworks tels que Cordova ou Ionic, qui permettent de développer des applications mobiles en se servant de technologies web. Les applications mobiles ne sont plus, logiquement, à l’abri des injections Javascript.

Défi 27 : Comment la tendance BYOA peut-elle affecter la sécurité ?

BYOA signifie « bring your own application » : cette tendance désigne par exemple les employés utilisant Google Docs avec leur compte personnel en lieu et place du SharePoint de leur entreprise.

Plusieurs points peuvent être soulevés :

  • En stockant des informations sur un outil tiers de son choix (souvent un cloud), l’utilisateur endosse la responsabilité de leur sécurité et devient en même temps dépendant du niveau de sécurité de l’application choisie. Un aspect que ni lui, ni son entreprise, ne maîtrisent. Un éditeur de bonne foi n’est pas à l’abris d’une fuite de données. En outre, l’utilisation des données stockées sur un outil tiers ne peut pas être entièrement maîtrisée.
  • En cas de vol de son ordinateur, l’utilisateur est le seul à pouvoir mettre en oeuvre la protection de ses données (changement immédiat des mots de passe).
  • En cas de vol d’identifiants, l’utilisateur n’a plus aucune prise sur l’utilisation du contenu qu’il a stocké sur un outil tiers.

Pour répondre à ces risques, certaines entreprises mettent en place une politique d’utilisation de logiciels tiers afin de sensibiliser aux menaces de cette tendance et de responsabiliser les employés.

Défi 28 : Partager des idées concernant les tests de sécurité dans un domaine particulier

Nous avons choisi de ne pas nous pencher sur un domaine en particulier, mais plutôt sur un type d’applicatif que nous utilisons quotidiennement : les logiciels open-source.

Logiquement, les failles d’un logiciel open source sont plus susceptibles d’être découvertes par le public que celles d’un logiciel propriétaire. Mais elles sont également plus susceptibles d’être révélées à son éditeur par la communauté, et donc plus vite corrigées. A contrario, les failles d’un logiciel propriétaires ne sont susceptibles d’être découvertes que par son éditeur lui-même, ou par les hackers black et grey hat. Les logiciels propriétaires ne sont pas à l’abris du reverse engineering, une pratique pourtant souvent interdite par les conditions générales d’utilisation.

Voici quelques articles ressources que nous avons trouvé sur le sujet :

… Défi 15 : S’exprimer sur les tests de sécurité sur les réseaux sociaux ou un blog

Voilà qui est fait. Déjà la fin des 28 jours de test de sécurité ! Si vous aussi avez participé au défi, laissez-nous un commentaire avec vos articles de blog, nous sommes curieux de les lire.

Découvrez nos autres séries d'articles !

Notre saga du test audiovisuel

Le kit de secours métaphorique du testeur agile

Notre série dédiée à Protractor

Un avis ? Un commentaire ?

Cet espace est pour vous.