En tant que développeurs et architectes, il est de notre devoir de fournir à nos clients des logiciels fiables, performants, maintenables et sûrs. Avec l’émergence mouvement Craft, de nombreux documents abordent les trois premiers points, mais peu s’attardent sur l’aspect sécurité.

Nous allons donc tenter de remédier à ça, et commencer une série d’articles consacrés à la question de la sécurité applicative. Bien que cette série ait vocation à être utile à tous les développeurs, nous nous intéresseront plus particulièrement à la sécurité des applications web ASP.NET MVC. Réduire ainsi le périmètre d’exploration nous permettra de traiter le sujet plus en profondeur. Libre à vous ensuite d’adapter le contenu à la plateforme de votre choix.

L’OWASP, c’est quoi ?

Aujourd’hui, la référence en matière de sécurité des applications web (et maintenant mobiles) est un organisme à but non lucratif appelé OWASP – pour Open Web Application Security Project. Depuis ses débuts en 2004, l’OWASP s’est fixé comme mission d’améliorer la sécurité du web en mettant librement à notre disposition documents, articles et projets en tous-genres. Mais de loin, le projet le plus connu de l’OWASP est son fameux TOP 10, publié tous les 3-4 ans, qui recense les 10 problèmes de sécurité les plus courants sur nos applications.

Pourquoi le Top 10 ?graphique 80-20

D’abord et avant tout, parce que ça me fait un bon fil conducteur pour une série de posts! Mais surtout, parce que les 10 risques les plus importants constituent un excellent point de départ pour sécuriser votre code. Le Top 10 permet d’appliquer le principe de Pareto: une fois que vous aurez terminé d’en lire et d’en comprendre le contenu, vous serez équipés pour protéger vos applications web de 80% des attaques pour seulement 20% du budget qu’il faudrait pour protéger les protéger à 100%*.

* OK, OK… dans la vraie vie, il est impossible de sécuriser totalement une application  (nous en reparlerons ultérieurement). Cependant, on peut dépenser des sommes énormes à tenter de se protéger des toutes les attaques du monde, y compris celles dont la probabilité est très faible. L’ingénieur pragmatique qui est en nous fait le ratio coût / bénéfice.

Lire la matrice

Pour chacun des problèmes de sécurité de son classement, l’OWASP nous présente une matrice comme celle-ci

matrice

C’est beau, mais ça représente quoi ?

La matrice donne des informations générales sur les risques de sécurité des applications. Ces données, combinées à vos connaissances sur votre application et votre entreprise vous permettront d’évaluer le risque que vous courrez. On évalue un risque en fonction des 3 points suivants:

  • Qui / qu’est ce qui représente une menace?
  • La probabilité que “la chose” se produise
  • L’impact de ladite “chose” (en partie mesurable de manière objective et en partie dépendante du business)

Identifier la menace

C’est la première colonne de la matrice , sous le titre “agents de menace”. Le travail d’identification de ces agents vous incombe: vous seul, dans votre entreprise, pouvez savoir qui ou qu’est-ce qui peut représenter une menace. Tout dépend de votre métier et de votre application. Ainsi, un site grand public tel que Rencontric pourra-être la cible de n’importe quel internaute, bot, etc…. A l’inverse, une application intranet sera probablement exposée au personnel malveillant de l’entreprise.

Déterminer la probabilité d’attaque (réussie)

C’est là qu’entre en scène le classement de l’OWASP.  La mesure est faite de manière statistique, sur la base de questions adressées aux entreprises et aux experts de l’industrie:

  • Quelles sont les attaques dont vous avez été victime/témoin? (prévalence)
  • La vulnérabilité à l’origine de l’attaque est-elle facile à trouver? (détectabilité)
  • Est-il facile d’exploiter la faille une fois celle-ci repérée? (exploitabilité)
  • Quelles sont les conséquences de l’attaque? (vol de données, perte de contrôle d’un serveur, déni de service…)

Les réponses à ces questions permettent de dresser un panorama des risques dans la nature. La probabilité d’une attaque réussie dépend de trois caractéristiques (prévalence, détectabilité, exploitabilité) des failles dans nos applications. En donnant une note à ces caractéristiques, on obtient une image représentant la difficulté du chemin que doit parcourir un agent de menace  – a.k.a. attaquant – pour arriver à son but

low_risk_high_risk

Evaluer l’impact

Pour mesurer l’impact d’une attaque réussie sur votre entreprise, il faut savoir ce que l’attaque en question permet de faire. Certaines donnent à l’attaquant la possibilité de voir des informations confidentielles, de modifier des données en base sans autorisation, de rendre votre application indisponible ou même de le prendre contrôle d’un serveur. La gravité de ces scénarios peut être évaluée de manière objective. C’est  se qu’on retrouve dans la colonne “impact technique” de la matrice.

Une fois que l’on a conscience de ce qui peut arriver en cas d’attaque réussie, on peut en mesurer l’impact sur notre business. Alors qu’une entreprise peut se permettre de voir son site indisponible pour une heure, une autre peut générer plusieurs millions de chiffre d’affaire sur cette durée. Toutes deux ne ressentiront pas le même degré d’importance à se protéger d’un déni de service et ne seront pas prête à investir les même sommes pour ce faire. Dans les deux cas, l’effort de sécurisation aura un coût. C’est à  nous, avec nos connaissances de notre application et de notre métier, de juger si le jeu en vaut la chandelle.

Et les couleurs dans tout ça?

Vous aurez remarqué que pour tous les critères “quantifiables” permettant d’évaluer un risque, l’OWASP a utilisé un code couleur innovant. Mémorisez bien le schéma suivant. C’est la pilule rouge, qui vous donnera le pouvoir de lire la matrice de tous les TOP 10s passés, présents et à venir.

 

owasp_colors

 

 

Dans le prochain article, nous rentrerons dans le vif du sujet et passerons en revue les 10 vainqueurs du TOP 10. Stay tuned for our next episode.