Failles applicatives

owasp_logo_150_150Précédemment, j’ai souhaité par le biais de l’article La sécurité au travers de l’OWASP amener une première réflexion sur la sécurité applicative au travers du guide OWASP. J’aimerais cette fois-ci aller plus loin et détailler un certain nombre de vulnérabilités. Cet article fera office de préface et référencera tous les articles sur ce thème.

Introduction

Dans le milieu du développement informatique, la sécurité est trop souvent mise de coté, et ce, pour plusieurs raisons comme par exemple :

  • Ignorance ;
  • Manque de budget ;
  • Manque de considération de la difficulté d’exploitation ;
  • Confiance aveugle dans l’utilisation d’outils tiers dont le projet dépend ;
  • Confiance aveugle envers les acteurs du système d’information.

C’est pourquoi, en partant de ce prédicat, j’ai souhaité, par le biais de quelques articles, démystifier des vulnérabilités connues et souvent exploitées. Ceci afin que chaque développeur puisse se forger une culture sur la sécurité, qui lui permettra de développer en étant conscient des menaces et des risques qui pèsent sur son système d’information.

Il existe un très grand nombre de vulnérabilités mais il est impossible de toutes les présenter, chaque article servira de base à une réflexion sur la sécurité uniquement et suivra le plan suivant :

1. Qualification de la menace

Chaque jour, de nouvelles vulnérabilités sont découvertes, or, nous ne pouvons nous prémunir contre leur totalité. Chaque projet ayant son propre référentiel de criticité, il est nécessaire au préalable de répondre à plusieurs questions :

  • Est-ce que le système d’information est critique ? Héberge-t-il des données sensibles ? Le service offert doit-il être disponible en continu et sans interruption ?
  • Contre quoi souhaitons-nous être protégé ? Il faut savoir être réaliste quant à la capacité des différents intervenants sur un projet réel et de l’écosystème mis en place car, une protection totale n’existe pas pour toutes les vulnérabilités, il est présomptueux de penser que notre application est intouchable. De plus, un client n’aura pas forcement les capacités financières de protéger son SI comme un développeur n’aura pas forcement les connaissances nécessaires (ou compétences) suffisantes à la sécurisation du code applicatif.
  • Que risquons-nous si cette vulnérabilité est découverte et exploitée ?
  • Quels impacts techniques l’exploitation amènera-t-elle ? Quels acteurs du système d’information sont impactés et sur quels points ? Est-ce que notre “Business Plan” le supportera ?
  • Quel coût aura un plan de restauration ? Est-il acceptable ou non ?

Une fois le périmètre défini, on est en mesure de prioriser l’implémentation de correctifs de sécurité.

2. Exemples d’exploitations

Comprendre les mécanismes d’un outil ainsi que ses dérives permet de mieux appréhender le sujet, donc : savoir exploiter une vulnérabilité (ou connaître son ou ses vecteurs d’attaque) nous donne suffisamment de recul pour être en mesure de développer un correctif. Cette analogie est souvent vérifiée dans le milieu de la sécurité informatique.

3. Méthodes de défense

Comme énoncé précédemment, une fois la technique d’exploitation de la vulnérabilité comprise, des moyens de vous en prémunir vous seront proposés. Chaque outil est différent et dispose de mécanismes qui lui sont propres, mais pour répondre souvent à la même problématique de base. C’est pourquoi pour toucher un maximum de personnes, j’ai décidé d’utiliser pour mes exemples des technologies éprouvées, adaptées pour la plupart des sites Internet et majoritairement utilisés (à savoir PHP comme langage exécuté côté serveur et MySQL comme SGBD).

Orienter un projet sur un axe sécuritaire, c’est aussi améliorer la qualité intrinsèque de l’application. C’est un cycle itératif qui nécessite de nombreuses remises en question. Cette démarche correspond à la méthode de gestion de qualité dite PDCA (Plan-Do-Check-Act) illustrée par la “Roue de Deming”.

Comme le souligne un article sur Wikipédia (cf : http://fr.wikipedia.org/wiki/Roue_de_Deming), la méthode comporte quatre étapes, chacune entraînant l’autre, et vise à établir un cercle vertueux. Sa mise en place doit permettre d’améliorer sans cesse la qualité d’un produit, d’une œuvre, d’un service, etc.

  1. Plan : Préparer, planifier (ce que l’on va réaliser)
  2. Do : Développer, réaliser, mettre en œuvre (le plus souvent, on commence par une phase de test)
  3. Check : Contrôler, vérifier
  4. Act (ou Adjust) : Agir, ajuster, réagir (si on a testé à l’étape Do, on déploie lors de la phase Act)

Tout au long de ces articles, je me baserai sur l’OWASP (Open Web Application Security Project, qui sera mon support d’informations principal), sur des sources que je citerai en annexe ainsi que mon expérience personnelle.

Articles sur la sécurité applicative

Webographie