{"id":3471,"date":"2021-02-01T14:11:52","date_gmt":"2021-02-01T13:11:52","guid":{"rendered":"https:\/\/www.vaadata.com\/blog\/?p=3471"},"modified":"2021-07-06T11:59:08","modified_gmt":"2021-07-06T09:59:08","slug":"comment-renforcer-la-securite-de-vos-applications-web-pour-contrer-les-attaques-les-plus-courantes","status":"publish","type":"post","link":"https:\/\/www.vaadata.com\/blog\/fr\/comment-renforcer-la-securite-de-vos-applications-web-pour-contrer-les-attaques-les-plus-courantes\/","title":{"rendered":"Comment renforcer la s\u00e9curit\u00e9 de vos applications web pour contrer les attaques les plus courantes ?"},"content":{"rendered":"\n<div class=\"wp-block-image\"><figure class=\"alignright size-large is-resized\"><img decoding=\"async\" src=\"https:\/\/www.vaadata.com\/blog\/wp-content\/uploads\/2021\/01\/securite-applications-web.jpg\" alt=\"Comment renforcer la s\u00e9curit\u00e9 de vos applications web\" class=\"wp-image-3472\" width=\"387\" height=\"188\"\/><\/figure><\/div>\n\n\n\n<p>La plupart des <strong>applications web<\/strong> manipulent des donn\u00e9es personnelles et\/ou des donn\u00e9es business&nbsp;; autant dire des donn\u00e9es sensibles. Mots de passe, adresses email, num\u00e9ros de cartes bancaires, donn\u00e9es sant\u00e9 et autres, sont au centre de la bataille qui oppose deux camps. D\u2019un c\u00f4t\u00e9 les entreprises, de petite, moyenne ou grande taille, qui cherchent \u00e0 se d\u00e9fendre contre des intrusions dans leurs syst\u00e8mes d\u2019information. Et de l\u2019autre, des assaillants de plus en plus exp\u00e9riment\u00e9s, attir\u00e9s par l\u2019app\u00e2t du gain et stimul\u00e9s par les nombreuses br\u00e8ches trop souvent ignor\u00e9es par leurs futures victimes. &nbsp; <\/p>\n\n\n\n<!--more-->\n\n\n\n<h2 class=\"wp-block-heading\">Les applications web, cibles principales des cyberattaques<\/h2>\n\n\n\n<p>\u00c9tant expos\u00e9es au public, les applications web ont naturellement une surface d\u2019attaque \u00e9tendue et \u00e9ventuellement des fonctionnalit\u00e9s avec un grand nombre d\u2019\u00e9l\u00e9ments vari\u00e9s potentiellement vuln\u00e9rables. M\u00eame sur un serveur Web s\u00e9curis\u00e9 s\u2019ex\u00e9cutant sur un syst\u00e8me d\u2019exploitation r\u00e9put\u00e9 s\u00fbr, des failles de s\u00e9curit\u00e9 peuvent subsister car elles sont la plupart du temps dues \u00e0 des fautes de programmation de l\u2019application elle-m\u00eame ou des erreurs du configuration du serveur l\u2019h\u00e9bergeant.<\/p>\n\n\n\n<p>Dans ce premier billet, d\u2019une s\u00e9rie d\u2019articles consacr\u00e9e aux failles les plus courantes rencontr\u00e9es lors de nos tests d\u2019intrusion, nous nous focaliserons sur les <strong>vuln\u00e9rabilit\u00e9s de la couche applicative des plateformes web<\/strong>. Nous reviendrons plus en d\u00e9tail sur la s\u00e9curit\u00e9 des serveurs et des APIs dans nos prochains articles.<\/p>\n\n\n\n<p>Par ailleurs, cet article n\u2019est pas un jugement \u00e0 charge, dans le sens o\u00f9 nous avons conscience des contraintes auxquelles font face de nombreuses \u00e9quipes de d\u00e9veloppement, CTO ou RSSI&nbsp;: budget, disponibilit\u00e9, organisation, etc. Il n\u2019est pas non plus \u00e0 d\u00e9charge, car les attaques r\u00e9ussissent tr\u00e8s souvent, en raison de n\u00e9gligences qui pourraient \u00eatre facilement \u00e9vit\u00e9es. L\u2019objectif de cet article est de montrer en quoi il est important de porter une attention \u00ab&nbsp;s\u00e9curit\u00e9&nbsp;\u00bb particuli\u00e8re, d\u00e8s la phase de conception, tout au long du d\u00e9veloppement et du cycle de vie de vos applications web pour se pr\u00e9munir contre des attaques de plus en plus nombreuses et sophistiqu\u00e9es.<\/p>\n\n\n\n<p>Mettre en place des mesures de s\u00e9curit\u00e9 adapt\u00e9es \u00e0 vos enjeux, sensibiliser ou former vos \u00e9quipes, r\u00e9aliser des tests d\u2019intrusion sont autant de leviers disponibles pour renforcer votre s\u00e9curit\u00e9 et parer les \u00e9ventuelles attaques que nous pr\u00e9sentons dans cet article.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Quelles sont les vuln\u00e9rabilit\u00e9s courantes des applications web et comment se prot\u00e9ger&nbsp;?<\/h2>\n\n\n\n<h3 class=\"has-text-color wp-block-heading\" style=\"color:#d6e322\">Fonction authentification et attaques par force brute<\/h3>\n\n\n\n<p>Bien \u00e9videmment, une application web peut \u00eatre attaqu\u00e9e de front. Cibler la fonction d\u2019authentification est l\u2019attaque la plus directe et \u00e9vidente. L\u2019attaque la plus courante contre les syst\u00e8mes d\u2019authentification est l\u2019attaque par force brute. Dans ce cas de figure, un attaquant, via&nbsp;l\u2019utilisation d\u2019outils sp\u00e9cifiques, bombarde une page d&rsquo;authentification avec des valeurs d&rsquo;identifiant et de mots de passe jusqu&rsquo;\u00e0 ce qu\u2019il obtienne un acc\u00e8s \u00e0 une application web.<\/p>\n\n\n\n<p>Ce type d\u2019attaque est facilit\u00e9 si le message d&rsquo;erreur de l&rsquo;\u00e9chec de l&rsquo;authentification donne l&rsquo;origine de l&rsquo;erreur. Ainsi \u00ab&nbsp;l&rsquo;utilisateur n&rsquo;existe pas&nbsp;\u00bb permet \u00e0 l&rsquo;attaquant de ne pas tenter d&rsquo;entrer des mots de passe pour cet utilisateur absent de la base de compte. \u00ab&nbsp;Mot de passe incorrect&nbsp;\u00bb permet \u00e0 l&rsquo;attaquant de se concentrer sur cet utilisateur, ce qui lui fait gagner beaucoup de temps.<\/p>\n\n\n\n<p>Il existe de nombreuses variantes d\u2019attaques par force brute. Le \u00ab&nbsp;password spraying&nbsp;\u00bb, qui consiste \u00e0 tester un ensemble limit\u00e9 de mots de passe sur plusieurs comptes, en est une. En effet, dans ce cas de figure, les attaquants tentent d\u2019acc\u00e9der \u00e0 une plateforme en testant un petit nombre de mots de passe couramment utilis\u00e9s, et ce sur un grand nombre de comptes. Ils partent du principe qu&rsquo;au sein d&rsquo;un grand groupe de personnes, il est probable qu&rsquo;il y en ait au moins une qui utilise un mot de passe commun, et c\u2019est malheureusement trop souvent le cas.<\/p>\n\n\n\n<p>Cette approche plus lente leur permet de tenter d&rsquo;acc\u00e9der \u00e0 plusieurs comptes sans \u00eatre bloqu\u00e9s, ce qui pourrait alerter la cible de l\u2019attaque. Un exemple concret d\u2019attaque par \u00ab&nbsp;password spraying&nbsp;\u00bb que nous avons r\u00e9alis\u00e9 dans le cadre d\u2019un test d\u2019intrusion en boite noire sur une application SaaS&nbsp;: &nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Extraction des profils LinkedIn de l\u2019entreprise<\/li><li>Cr\u00e9ation des emails \u00e0 partir du nom, pr\u00e9nom et du pattern nom.prenom@entreprise.com<\/li><li>Password spraying sur le backoffice en utilisant une petite liste de mots de passe&nbsp;: Entreprise, entreprise, entreprise2021, Entreprise2021, entreprise2021! et Entreprise2021!<\/li><li>Obtention d\u2019un compte administrateur avec acc\u00e8s au backoffice<\/li><li>Extraction de la liste de tous les utilisateurs avec acc\u00e8s au backoffice<\/li><li>A nouveau password spraying, qui a permis d\u2019obtenir d\u2019autres comptes<\/li><\/ul>\n\n\n\n<p>Les attaques par force brute sont redoutables et ne sont pas \u00e0 prendre \u00e0 la l\u00e9g\u00e8re. Il est conseill\u00e9 de mettre en place des mesures techniques anti \u00ab&nbsp;brute force&nbsp;\u00bb, comme&nbsp;:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>S\u00e9curiser le m\u00e9canisme de login en limitant le nombre de connexions non valides et en augmentant le d\u00e9lai apr\u00e8s et entre chaque tentative de login. <\/li><li>Mettre en place un syst\u00e8me d\u2019authentification multi-facteurs (au moins deux), afin de s\u2019assurer que le processus de login est bien r\u00e9alis\u00e9 par une personne et non un bot. Il peut s\u2019agir d\u2019une r\u00e9ponse \u00e0 une question secr\u00e8te, le renseignement d\u2019un code re\u00e7u par SMS, ou de r\u00e9pondre \u00e0 un test Captcha.<\/li><\/ul>\n\n\n\n<p>D\u2019autres mesures simples (politique de mots de passe forts, messages d\u2019erreur g\u00e9n\u00e9riques, consultation r\u00e9guli\u00e8re des journaux de logs, etc.), une sensibilisation continue et des <a href=\"https:\/\/www.vaadata.com\/fr\/formations-securite-hacking\/\" target=\"_blank\" rel=\"noreferrer noopener\">formations sur la s\u00e9curit\u00e9 web<\/a>, sont de bons moyens de se pr\u00e9munir contre ce type d\u2019attaque.<\/p>\n\n\n\n<h3 class=\"has-text-color wp-block-heading\" style=\"color:#d6e322\">Gestion des droits d\u2019acc\u00e8s et \u00e9l\u00e9vation de privil\u00e8ges<\/h3>\n\n\n\n<p>Les utilisateurs d\u2019une application sont cens\u00e9s \u00eatre dignes de confiance et respecter les politiques de s\u00e9curit\u00e9 en place. Mais le sont-ils toujours ? Des utilisateurs l\u00e9gitimes ont de nombreuses raisons potentielles de devenir \u00ab&nbsp;malveillant&nbsp;\u00bb \u00e0 certains moments&nbsp;:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Pour \u00e9viter une proc\u00e9dure qu\u2019ils ne comprennent pas et qu\u2019ils peuvent contourner, en utilisant une fonctionnalit\u00e9 \u00e0 laquelle ils ne sont pas suppos\u00e9s avoir acc\u00e8s<\/li><li>Pour avoir acc\u00e8s aux donn\u00e9es d\u2019un autre utilisateur pour des raisons diverses<\/li><li>Pour acc\u00e9der \u00e0 des fonctionnalit\u00e9s r\u00e9serv\u00e9es \u00e0 un groupe d\u2019utilisateurs, comme par exemple utiliser gratuitement des services payants<\/li><\/ul>\n\n\n\n<p>La gestion des droits d\u2019acc\u00e8s est un \u00e9l\u00e9ment central dans la s\u00e9curit\u00e9 des applications web. C\u2019est s\u00fbrement l\u2019aspect le plus cibl\u00e9 par des attaquants malveillants, souhaitant \u00ab&nbsp;\u00e9lever leurs privil\u00e8ges&nbsp;\u00bb pour parvenir \u00e0 leurs fins. On parle en effet d\u2019\u00e9l\u00e9vation de privil\u00e8ges lorsqu&rsquo;un utilisateur exploite une faille, un d\u00e9faut de conception ou une erreur de configuration dans une application pour obtenir un acc\u00e8s \u00e9lev\u00e9 \u00e0 des ressources qui devraient normalement lui \u00eatre inaccessibles. Il peut alors utiliser les privil\u00e8ges nouvellement acquis pour voler des donn\u00e9es confidentielles, ex\u00e9cuter des commandes administratives ou d\u00e9ployer des logiciels malveillants&nbsp;; et potentiellement causer de graves dommages \u00e0 votre syst\u00e8me d\u2019information et votre image de marque.<\/p>\n\n\n\n<p>G\u00e9n\u00e9ralement, les attaquants commencent par exploiter une vuln\u00e9rabilit\u00e9 au niveau des droits d\u2019acc\u00e8s dans un syst\u00e8me ou une application cible, ce qui leur permet de passer outre les limitations du compte utilisateur actuel. Ils peuvent ensuite acc\u00e9der aux fonctionnalit\u00e9s et aux donn\u00e9es d&rsquo;un autre utilisateur. Puis leur objectif consistera \u00e0 obtenir des privil\u00e8ges \u00e9lev\u00e9s, g\u00e9n\u00e9ralement ceux d&rsquo;un administrateur (le Graal&nbsp;!) ou d&rsquo;un autre utilisateur puissant.<\/p>\n\n\n\n<p>Un exemple concret que nous avons r\u00e9alis\u00e9 dans le cadre d\u2019un test d\u2019intrusion en boite grise sur une application SaaS&nbsp;: &nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Acc\u00e8s \u00e0 un compte utilisateur standard dans l\u2019environnement de production, avec des actions limit\u00e9es au sein du back-office&nbsp;: consultation de documents, envoi de demandes de divers types via syst\u00e8me de workflows, etc.<\/li><li>Gr\u00e2ce \u00e0 un bug dans le back-office li\u00e9 aux param\u00e8tres d\u2019URLs, il a \u00e9t\u00e9 possible d\u2019acc\u00e9der \u00e0 des fonctionnalit\u00e9s disponibles \u00e0 l\u2019\u00e9quipe support uniquement, ayant notamment la possibilit\u00e9 de mettre \u00e0 jour les adresses email de tous les autres utilisateurs de la solution (dont les personnes disposant de droits super admin sur le back-office)<\/li><li>Ces fonctionnalit\u00e9s de l\u2019\u00e9quipe support nouvellement acquises, il a \u00e9t\u00e9 possible de modifier l\u2019email d\u2019un super admin et de r\u00e9initialiser le mot de passe via la notification email re\u00e7u en ce sens<\/li><\/ul>\n\n\n\n<p>Heureusement, cette vuln\u00e9rabilit\u00e9 critique a \u00e9t\u00e9 d\u00e9couverte dans le cadre d\u2019un test d\u2019intrusion. Nul besoin de pr\u00e9ciser en quoi les cons\u00e9quences auraient \u00e9t\u00e9 d\u00e9sastreuses pour l\u2019entreprise si jamais une attaque de ce type \u00e9tait survenue.<\/p>\n\n\n\n<p>Les applications constituent le point d&rsquo;entr\u00e9e le plus facile pour toute attaque, il est donc vital de les s\u00e9curiser&nbsp;: impl\u00e9menter les meilleures pratiques de d\u00e9veloppement pour \u00e9viter les erreurs de programmation et de configuration, utiliser des scanners de vuln\u00e9rabilit\u00e9 pour v\u00e9rifier si vos applications sont faillibles, et r\u00e9aliser des tests d\u2019intrusion pour assurer que les niveaux de droits impl\u00e9ment\u00e9s sont bien segment\u00e9s et cloisonn\u00e9s.<\/p>\n\n\n\n<div class=\"wp-block-buttons is-layout-flex wp-block-buttons-is-layout-flex\">\n<div class=\"wp-block-button is-style-fill\"><a class=\"wp-block-button__link\" href=\"https:\/\/resources.vaadata.com\/cas-client-pentest-editeur-de-logiciel\" target=\"_blank\" rel=\"noreferrer noopener\">T\u00c9L\u00c9CHARGEZ NOTRE CAS CLIENT  \u00c9DITEUR DE LOGICIEL<\/a><\/div>\n<\/div>\n\n\n\n<h3 class=\"has-text-color wp-block-heading\" style=\"color:#d6e322\">Exploitation de failles XSS &nbsp;<\/h3>\n\n\n\n<p>Supposons que la porte du back-office d\u2019une application web soit solide, et son enceinte prot\u00e9g\u00e9e par des remparts imp\u00e9n\u00e9trables. Les attaquants \u00ab irr\u00e9ductibles&nbsp;\u00bb se tourneront alors vers le front-office pour essayer d\u2019injecter du contenu malveillant dans l\u2019application via n\u2019importe quel champ ou syst\u00e8me d\u2019envoi de donn\u00e9es disponible.<\/p>\n\n\n\n<p>Le Cross Site Scripting (abr\u00e9g\u00e9 XSS) est une vuln\u00e9rabilit\u00e9 courante des applications web qui, bien exploit\u00e9e, peut permettre de voler une session, remplacer une partie de l&rsquo;interface utilisateur, t\u00e9l\u00e9charger des logiciels malveillants [etc.] via de l\u2019injection de code (JavaScript, HTML, CSS). Il existe 2 types d\u2019attaques XSS&nbsp;:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Les attaques XSS stock\u00e9es (stored XSS attacks) qui envoient un contenu malicieux sur le serveur h\u00e9bergeant une application web, afin qu\u2019il soit renvoy\u00e9 dans le navigateur des utilisateurs. &nbsp;<\/li><\/ul>\n\n\n\n<ul class=\"wp-block-list\"><li>Les attaques XSS refl\u00e9t\u00e9es (reflected XSS attacks) qui ne stockent pas le contenu malicieux sur le serveur web, mais qui le livrent aux utilisateurs de l\u2019application via une URL ou directement sur le navigateur.<\/li><\/ul>\n\n\n\n<p>En somme, les attaques XSS reposent sur l\u2019envoi de contenus malicieux affich\u00e9s sur le navigateur des utilisateurs d\u2019une application web, sous forme de pop-up ou une redirection vers un site externe.<\/p>\n\n\n\n<p>Il est difficile de d\u00e9tailler toutes les cons\u00e9quences possibles des attaques XSS, la liste serait tr\u00e8s longue. Pour s\u2019en prot\u00e9ger, il faut partir du principe que&nbsp;les donn\u00e9es re\u00e7ues par une application web ne peuvent pas \u00eatre consid\u00e9r\u00e9es comme \u00ab&nbsp;toujours&nbsp;\u00bb s\u00fbres. Il est important de suivre des r\u00e8gles strictes pour traiter les donn\u00e9es venant de l\u2019ext\u00e9rieur. Tout contenu doit \u00eatre nettoy\u00e9, valid\u00e9 et\/ou encod\u00e9&nbsp;avant d\u2019\u00eatre utilis\u00e9 par l\u2019application. Les scanners de vuln\u00e9rabilit\u00e9s peuvent rep\u00e9rer certaines de ces vuln\u00e9rabilit\u00e9s, mais un test d\u2019intrusion ou une revue de code seront plus complets.<\/p>\n\n\n\n<h3 class=\"has-text-color wp-block-heading\" style=\"color:#d6e322\">Les attaques par injection SQL<\/h3>\n\n\n\n<p>Les attaques par injection&nbsp;sont facilit\u00e9es par le fonctionnement m\u00eame des applications web, car elles ont besoin de donn\u00e9es pour fonctionner. Et plus il faut de donn\u00e9es, plus les opportunit\u00e9s d&rsquo;attaques par injection sont nombreuses.<\/p>\n\n\n\n<p>Une vuln\u00e9rabilit\u00e9 courante&nbsp;: les failles d\u2019injection SQL&nbsp;; qui permettent d\u2019interagir avec la base de donn\u00e9es d\u2019une application par le biais de requ\u00eates non-pr\u00e9vues. Ces failles peuvent conduire \u00e0 des vols, pertes de donn\u00e9es, une suppression ou une manipulation des donn\u00e9es stock\u00e9es.<\/p>\n\n\n\n<h3 class=\"has-text-color wp-block-heading\" style=\"color:#d6e322\">S\u00e9curit\u00e9 des syst\u00e8mes interconnect\u00e9s <\/h3>\n\n\n\n<p>Les applications web sont souvent reli\u00e9es \u00e0 des services ou syst\u00e8mes tiers, notamment pour faire communiquer des donn\u00e9es. La plupart des FinTech utilisent par exemple des syst\u00e8mes de paiement, d\u00e9velopp\u00e9s et commercialis\u00e9s par des tiers, pour les int\u00e9grer \u00e0 leurs applications web maison. Ces syst\u00e8mes de paiement sont g\u00e9n\u00e9ralement s\u00e9curis\u00e9s car il existe de nombreux standards en mati\u00e8re de s\u00e9curit\u00e9 dans le domaine du paiement \u00e9lectronique, notamment PCI-DSS.<\/p>\n\n\n\n<p>Vous l\u2019aurez compris, une application tierce peut \u00eatre robuste sur le plan de la s\u00e9curit\u00e9, mais des vuln\u00e9rabilit\u00e9s apparaissent tr\u00e8s souvent en raison d\u2019un probl\u00e8me de configuration et\/ou d\u2019impl\u00e9mentation du syst\u00e8me d\u2019interconnexion (web services, APIs&nbsp;: nous reviendrons plus en d\u00e9tail sur les failles courantes et les bonnes pratiques de s\u00e9curit\u00e9 des APIs dans notre prochain article). &nbsp;<\/p>\n\n\n\n<div class=\"wp-block-buttons is-layout-flex wp-block-buttons-is-layout-flex\">\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link\" href=\"https:\/\/resources.vaadata.com\/cas-client-pentest-fintech\" target=\"_blank\" rel=\"noreferrer noopener\">T\u00c9L\u00c9CHARGEZ NOTRE CAS CLIENT FINTECH<\/a><\/div>\n<\/div>\n\n\n\n<h3 class=\"has-text-color wp-block-heading\" style=\"color:#d6e322\">S\u00e9curit\u00e9 des composants tiers<\/h3>\n\n\n\n<p>Les composants tiers sont un des points d\u2019attraction&nbsp;favoris des attaquants car la plupart des applications web en contiennent. Utiliser des librairies ou des frameworks est une pratique courante. Cela permet de d\u00e9velopper plus rapidement et plus facilement des applications, et ce, en tirant parti de l\u2019appui d\u2019une communaut\u00e9 active. Cependant, ces composants tiers sont expos\u00e9s \u00e0 des attaques web. Et pour ne pas arranger les choses, plus un composant est populaire, plus il est l\u2019objet d\u2019attaques. En effet, lorsqu\u2019une faille de s\u00e9curit\u00e9 est d\u00e9couverte sur un composant, elle devient souvent publique.<\/p>\n\n\n\n<p>La solution&nbsp;: un patch est d\u00e9velopp\u00e9 afin de corriger cette faille dans la nouvelle version, qui sera \u00ab&nbsp;normalement&nbsp;\u00bb install\u00e9e par les d\u00e9veloppeurs utilisant ces composants tiers. Le probl\u00e8me&nbsp;: les attaquants attendent \u00e9galement les mises \u00e0 jour contenant les d\u00e9tails des vuln\u00e9rabilit\u00e9s d\u00e9couvertes, afin de lancer rapidement des attaques sur des composants critiques.<\/p>\n\n\n\n<p>Les possibilit\u00e9s de failles sont, comme sur toute autre application, nombreuses (injections, XSS, failles d\u2019authentification, etc.). Un exemple rencontr\u00e9 dans le cadre d\u2019un test d\u2019intrusion en boite grise sur une application SaaS permettant la gestion de donn\u00e9es financi\u00e8res d&rsquo;entreprises&nbsp;: <\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Plateforme ferm\u00e9e du point de vue d&rsquo;un attaquant externe, seul un formulaire d&rsquo;authentification \u00e9tait accessible<\/li><li>Apr\u00e8s des tests approfondis et des recherches pouss\u00e9es en direction des composants tiers utilis\u00e9s, nous avons rep\u00e9r\u00e9 une librairie javaScript<\/li><li>La version install\u00e9e \u00e9tant ancienne, elle pr\u00e9sentait une vuln\u00e9rabilit\u00e9 connue qui permettait notamment de lire n&rsquo;importe quel fichier pr\u00e9sent sur le serveur l&rsquo;h\u00e9bergeant<\/li><li>En l&rsquo;exploitant, il a \u00e9t\u00e9 possible d&rsquo;extraire de nombreux fichiers sensibles pr\u00e9sents sur le serveur web, et d&rsquo;acc\u00e9der in fine \u00e0 l&rsquo;int\u00e9gralit\u00e9 des donn\u00e9es g\u00e9r\u00e9es par la plateforme web.<\/li><\/ul>\n\n\n\n<p>Pour contrer ces attaques, nous conseillons de limiter au maximum l\u2019utilisation de composants tiers, si vous disposez des ressources permettant de s\u2019en passer. Vous aurez toujours plus la main sur la s\u00e9curit\u00e9 d\u2019un d\u00e9veloppement-maison que d\u2019un composant externe.<\/p>\n\n\n\n<p>Si cela n\u2019est pas possible, il est important&nbsp;de maintenir \u00e0 jour une liste des composants tiers utilis\u00e9s sur votre application web, et leurs versions. Cela facilitera l\u2019identification des composants vuln\u00e9rables, et votre l\u2019\u00e9quipe de d\u00e9veloppement pourra agir si besoin, en ayant une connaissance pr\u00e9cise des \u00e9l\u00e9ments utilis\u00e9s. Pour ce faire, il est conseill\u00e9 d\u2019assurer une veille technique et technologique afin de surveiller les nouvelles versions disponibles et les vuln\u00e9rabilit\u00e9s d\u00e9couvertes sur les composants tiers utilis\u00e9s. S\u2019inscrire \u00e0 des mailing lists projets (celles des composants utilis\u00e9s), ou des mailings lists de s\u00e9curit\u00e9 sont autant de moyens de rester inform\u00e9 et sur le qui-vive. &nbsp;<\/p>\n\n\n\n<h3 class=\"has-text-color wp-block-heading\" style=\"color:#d6e322\">Au-del\u00e0 des failles techniques, des failles logiques souvent oubli\u00e9es<\/h3>\n\n\n\n<p>Les vuln\u00e9rabilit\u00e9s techniques sont inh\u00e9rentes aux applications web. Au-del\u00e0 de ces vuln\u00e9rabilit\u00e9s, il subsiste aussi des failles logiques qui, elles sont li\u00e9es aux workflows, et ind\u00e9tectables avec des outils automatiques (scanners et autres). Qu\u2019est-ce qu\u2019une faille logique&nbsp;?<\/p>\n\n\n\n<p>Une faille logique existe lorsque le fonctionnement normal d\u2019une application, autrement dit une \u00e9tape logique ou un processus pr\u00e9vu, peut \u00eatre \u00e9vit\u00e9 ou contourn\u00e9.<\/p>\n\n\n\n<p>Un exemple concret de faille logique d\u00e9couverte dans le cadre d\u2019un test d\u2019intrusion en boite noire sur une plateforme e-commerce&nbsp;: &nbsp;<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>Cr\u00e9ation d\u2019un compte pour effectuer des achats sur la plateforme<\/li><li>Ajout de produits dans le panier puis passage \u00e0 l\u2019\u00e9tape de validation du panier<\/li><li>Modification du prix des produits ajout\u00e9s au panier (sans changer leurs r\u00e9f\u00e9rences) en \u00e9ditant directement le code HTML, ce qui a entrain\u00e9 une baisse de la valeur \u00ab&nbsp;affich\u00e9e&nbsp;\u00bb de notre panier<\/li><li>Enfin, il a \u00e9t\u00e9 possible de valider le paiement de notre panier (\u00e0 tarif r\u00e9duit), car le prix indiqu\u00e9 dans la requ\u00eate de paiement envoy\u00e9e \u00e0 la banque prenait comme r\u00e9f\u00e9rence le prix du panier affich\u00e9 dans notre navigateur. &nbsp;&nbsp;&nbsp;<\/li><\/ul>\n\n\n\n<p>Ceci a \u00e9t\u00e9 possible car la plateforme n&rsquo;effectuait pas de v\u00e9rification et se fiait aux entr\u00e9es utilisateur. Afin de se pr\u00e9munir, il est pr\u00e9f\u00e9rable que le serveur indique le prix \u00e0 payer \u00e0 la banque en fonction de la r\u00e9f\u00e9rence des produits voulus. L&rsquo;affichage du prix cot\u00e9 utilisateur ne doit \u00eatre qu&rsquo;une indication visuelle pour lui-m\u00eame et non une valeur \u00e0 prendre en compte.<\/p>\n\n\n\n<p>En somme, les failles logiques sont g\u00e9n\u00e9ralement le r\u00e9sultat d\u2019un d\u00e9faut de conception des applications web ou d\u2019un manque de tests approfondis d\u2019un point de vue s\u00e9curit\u00e9. Et si tests s\u00e9curit\u00e9 il y a, il est n\u00e9cessaire de se focaliser sur ce que l\u2019application n\u2019est pas suppos\u00e9e permettre pour d\u00e9tecter ses faiblesses logiques.<\/p>\n\n\n\n<p>Pour ce faire, il est n\u00e9cessaire de bien comprendre le comportement attendu de l\u2019application, la logique et les r\u00e8gles m\u00e9tiers, les contr\u00f4les s\u00e9curit\u00e9 qui en d\u00e9coulent, et donc les potentiels abus fonctionnels, puis de faire preuve de cr\u00e9ativit\u00e9 pour construire des sc\u00e9narios impr\u00e9vus, et enfin les tester sur l\u2019application.<\/p>\n\n\n\n<div class=\"wp-block-buttons is-layout-flex wp-block-buttons-is-layout-flex\">\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link\" href=\"https:\/\/resources.vaadata.com\/cas-client-pentest-direction-ecommerce-groupe-retail\" target=\"_blank\" rel=\"noreferrer noopener\">T\u00c9L\u00c9CHARGEZ NOTRE CAS CLIENT E-COMMERCE<\/a><\/div>\n<\/div>\n\n\n\n<h2 class=\"wp-block-heading\">R\u00e9aliser des tests d\u2019intrusion d\u2019application web pour \u00e9valuer et r\u00e9duire les risques s\u00e9curit\u00e9<strong> &nbsp;<\/strong><\/h2>\n\n\n\n<p>Les <a href=\"https:\/\/www.vaadata.com\/fr\/pentest-web\/\" target=\"_blank\" rel=\"noreferrer noopener\">tests d\u2019intrusion d\u2019application web<\/a> sont la solution par excellence pour faire face aux attaques informatiques. Ne dit-on pas que la meilleure d\u00e9fense, c\u2019est l\u2019attaque&nbsp;! Cet adage r\u00e9sume parfaitement le principe des tests d\u2019intrusion, qui consistent en effet \u00e0 tester la s\u00e9curit\u00e9 d\u2019une application ou d\u2019un autre syst\u00e8me en r\u00e9alisant diverses attaques afin d\u2019identifier des vuln\u00e9rabilit\u00e9s techniques et logiques potentielles. &nbsp;<\/p>\n\n\n\n<p>Lors d\u2019un test d\u2019intrusion d\u2019application web, trois approches sont possibles&nbsp;: des tests en boite noire, des tests en boite grise ou des tests en boite blanche. Ces approches correspondent \u00e0 diff\u00e9rents niveaux d\u2019information et d\u2019acc\u00e8s fournis aux pentesters. Les tests d\u2019intrusion en boite noire ciblent la surface d\u2019attaque accessible \u00e0 n\u2019importe quel attaquant externe, tandis que des tests d\u2019intrusion en boite grise vont concerner des \u00e9l\u00e9ments disponibles avec des acc\u00e8s fournis par le Client (et non accessibles autrement). Un test d\u2019intrusion en boite blanche quant \u00e0 lui permet d\u2019analyser le niveau de s\u00e9curit\u00e9 en disposant de tout ou partie du code source de l\u2019application et d\u2019un acc\u00e8s \u00e0 l\u2019infrastructure l\u2019h\u00e9bergeant.<\/p>\n\n\n\n<p>Les tests d\u2019intrusion d\u2019application web permettent de rechercher des vuln\u00e9rabilit\u00e9s li\u00e9es \u00e0 la configuration des serveurs web ainsi que des vuln\u00e9rabilit\u00e9s li\u00e9es \u00e0 la couche applicative. C\u00f4t\u00e9 serveur, il s\u2019agit par exemple de services ouverts et mal s\u00e9curis\u00e9s, de logiciels non \u00e0 jour, ou d\u2019erreurs de configuration. Et nous reviendrons sur ce point dans notre prochain article. C\u00f4t\u00e9 applicatif, il s\u2019agit des vuln\u00e9rabilit\u00e9s r\u00e9pertori\u00e9es par l\u2019<a href=\"https:\/\/owasp.org\/www-project-top-ten\/\" target=\"_blank\" rel=\"noreferrer noopener\">OWASP<\/a> (les failles du top 10 dont certaines ont \u00e9t\u00e9 abord\u00e9es plus haut), ainsi que les failles logiques.<\/p>\n\n\n\n<p>Un rapport complet est remis suite \u00e0 un test d\u2019intrusion. Ce livrable inclut la m\u00e9thodologie employ\u00e9e, les vuln\u00e9rabilit\u00e9s identifi\u00e9es (classifi\u00e9es par niveau de criticit\u00e9&nbsp;: faible, importante, critique), l\u2019exploitation possible ainsi que des recommandations de correction. Une pr\u00e9sentation des r\u00e9sultats de l\u2019audit, par le(s) pentester(s) en charge de l\u2019audit permet d\u2019\u00e9changer sur les r\u00e9sultats de l\u2019audit de s\u00e9curit\u00e9.<\/p>\n\n\n\n<p>Chez Vaadata, nous d\u00e9mocratisons les tests d\u2019intrusion avec des offres adapt\u00e9es aux startups comme aux grandes entreprises. Il est tout autant possible de r\u00e9aliser un premier test d\u2019intrusion d\u2019une journ\u00e9e \u00e0 675 euros (incluant rapport et pr\u00e9sentation des r\u00e9sultats), que de partir sur un audit plus en profondeur avec un budget compris entre 2500 et 10 000 euros (tarif d\u00e9termin\u00e9 en fonction de la complexit\u00e9 fonctionnelle et technique et votre application web, ainsi que du niveau de profondeur souhait\u00e9).<\/p>\n\n\n\n<p>Contactez-nous pour toute question relative \u00e0 un projet de tests d\u2019intrusion sur votre application web. Nous \u00e9changerons sur vos besoins et vous proposerons une intervention adapt\u00e9e \u00e0 vos enjeux s\u00e9curit\u00e9 et vos contraintes, qu\u2019elles soient budg\u00e9taires ou organisationnelles.<\/p>\n\n\n\n<div class=\"wp-block-buttons is-layout-flex wp-block-buttons-is-layout-flex\">\n<div class=\"wp-block-button\"><a class=\"wp-block-button__link\" href=\"https:\/\/www.vaadata.com\/fr\/contact\/\" target=\"_blank\" rel=\"noreferrer noopener\">CONTACTEZ-NOUS<\/a><\/div>\n<\/div>\n\n\n\n\n\n<span class=\"hs-cta-wrapper\" id=\"hs-cta-wrapper-6abd6822-6c99-4200-bdb9-ca6083e1faf1\"><span class=\"hs-cta-node hs-cta-6abd6822-6c99-4200-bdb9-ca6083e1faf1\" id=\"hs-cta-6abd6822-6c99-4200-bdb9-ca6083e1faf1\"><!--[if lte IE 8]><div id=\"hs-cta-ie-element\"><\/div><![endif]--><a href=\"https:\/\/cta-redirect.hubspot.com\/cta\/redirect\/6645565\/6abd6822-6c99-4200-bdb9-ca6083e1faf1\" target=\"_blank\" rel=\"noopener\"><img decoding=\"async\" class=\"hs-cta-img\" id=\"hs-cta-img-6abd6822-6c99-4200-bdb9-ca6083e1faf1\" style=\"border-width:0px;\" height=\"459\" width=\"917\" src=\"https:\/\/no-cache.hubspot.com\/cta\/default\/6645565\/6abd6822-6c99-4200-bdb9-ca6083e1faf1.png\" alt=\"Comment d\u00e9finir le scope d'un pentest - T\u00e9l\u00e9charger\"><\/a><\/span><script charset=\"utf-8\" src=\"https:\/\/js.hscta.net\/cta\/current.js\"><\/script><script type=\"text\/javascript\"> hbspt.cta.load(6645565, '6abd6822-6c99-4200-bdb9-ca6083e1faf1', {\"region\":\"na1\"}); <\/script><\/span>\n","protected":false},"excerpt":{"rendered":"<p>La plupart des applications web manipulent des donn\u00e9es personnelles et\/ou des donn\u00e9es business&nbsp;; autant dire des donn\u00e9es sensibles. Mots de passe, adresses email, num\u00e9ros de cartes bancaires, donn\u00e9es sant\u00e9 et autres, sont au centre de la bataille qui oppose deux camps. D\u2019un c\u00f4t\u00e9 les entreprises, de petite, moyenne ou grande taille, qui cherchent \u00e0 se<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,13],"tags":[],"class_list":{"0":"post-3471","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-solutions","7":"category-solutions-fr"},"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/3471","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/comments?post=3471"}],"version-history":[{"count":13,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/3471\/revisions"}],"predecessor-version":[{"id":3803,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/3471\/revisions\/3803"}],"wp:attachment":[{"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/media?parent=3471"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/categories?post=3471"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/tags?post=3471"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}