Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

La plupart des applications web manipulent des données personnelles et/ou des d

La plupart des applications web manipulent des données personnelles et/ou des données business ; autant dire des données sensibles. Mots de passe, adresses email, numéros de cartes bancaires, données santé et autres, sont au centre de la bataille qui oppose deux camps. D’un côté les entreprises, de petite, moyenne ou grande taille, qui cherchent à se défendre contre des intrusions dans leurs systèmes d’information. Et de l’autre, des assaillants de plus en plus expérimentés, attirés par l’appât du gain et stimulés par les nombreuses brèches trop souvent ignorées par leurs futures victimes. Les applications web, cibles principales des cyberattaques Étant exposées au public, les applications web ont naturellement une surface d’attaque étendue et éventuellement des fonctionnalités avec un grand nombre d’éléments variés potentiellement vulnérables. Même sur un serveur Web sécurisé s’exécutant sur un système d’exploitation réputé sûr, des failles de sécurité peuvent subsister car elles sont la plupart du temps dues à des fautes de programmation de l’application elle- même ou des erreurs du configuration du serveur l’hébergeant. Dans ce premier billet, d’une série d’articles consacrée aux failles les plus courantes rencontrées lors de nos tests d’intrusion, nous nous focaliserons sur les vulnérabilités de la couche applicative des plateformes web. Nous reviendrons plus en détail sur la sécurité des serveurs et des APIs dans nos prochains articles. Par ailleurs, cet article n’est pas un jugement à charge, dans le sens où nous avons conscience des contraintes auxquelles font face de nombreuses équipes de développement, CTO ou RSSI : budget, disponibilité, organisation, etc. Il n’est pas non plus à décharge, car les attaques réussissent très souvent, en raison de négligences qui pourraient être facilement évitées. L’objectif de cet article est de montrer en quoi il est important de porter une attention « sécurité » particulière, dès la phase de conception, tout au long du développement et du cycle de vie de vos applications web pour se prémunir contre des attaques de plus en plus nombreuses et sophistiquées. Mettre en place des mesures de sécurité adaptées à vos enjeux, sensibiliser ou former vos équipes, réaliser des tests d’intrusion sont autant de leviers disponibles pour renforcer votre sécurité et parer les éventuelles attaques que nous présentons dans cet article. Quelles sont les vulnérabilités courantes des applications web et comment se protéger ? Fonction authentification et attaques par force brute Bien évidemment, une application web peut être attaquée de front. Cibler la fonction d’authentification est l’attaque la plus directe et évidente. L’attaque la plus courante contre les systèmes d’authentification est l’attaque par force brute. Dans ce cas de figure, un attaquant, via l’utilisation d’outils spécifiques, bombarde une page d’authentification avec des valeurs d’identifiant et de mots de passe jusqu’à ce qu’il obtienne un accès à une application web. Ce type d’attaque est facilité si le message d’erreur de l’échec de l’authentification donne l’origine de l’erreur. Ainsi « l’utilisateur n’existe pas » permet à l’attaquant de ne pas tenter d’entrer des mots de passe pour cet utilisateur absent de la base de compte. « Mot de passe incorrect » permet à l’attaquant de se concentrer sur cet utilisateur, ce qui lui fait gagner beaucoup de temps. Il existe de nombreuses variantes d’attaques par force brute. Le « password spraying », qui consiste à tester un ensemble limité de mots de passe sur plusieurs comptes, en est une. En effet, dans ce cas de figure, les attaquants tentent d’accéder à une plateforme en testant un petit nombre de mots de passe couramment utilisés, et ce sur un grand nombre de comptes. Ils partent du principe qu’au sein d’un grand groupe de personnes, il est probable qu’il y en ait au moins une qui utilise un mot de passe commun, et c’est malheureusement trop souvent le cas. Cette approche plus lente leur permet de tenter d’accéder à plusieurs comptes sans être bloqués, ce qui pourrait alerter la cible de l’attaque. Un exemple concret d’attaque par « password spraying » que nous avons réalisé dans le cadre d’un test d’intrusion en boite noire sur une application SaaS :  Extraction des profils LinkedIn de l’entreprise  Création des emails à partir du nom, prénom et du pattern nom.prenom@entreprise.com  Password spraying sur le backoffice en utilisant une petite liste de mots de passe : Entreprise, entreprise, entreprise2021, Entreprise2021, entreprise2021! et Entreprise2021!  Obtention d’un compte administrateur avec accès au backoffice  Extraction de la liste de tous les utilisateurs avec accès au backoffice  A nouveau password spraying, qui a permis d’obtenir d’autres comptes Les attaques par force brute sont redoutables et ne sont pas à prendre à la légère. Il est conseillé de mettre en place des mesures techniques anti « brute force », comme :  Sécuriser le mécanisme de login en limitant le nombre de connexions non valides et en augmentant le délai après et entre chaque tentative de login.  Mettre en place un système d’authentification multi-facteurs (au moins deux), afin de s’assurer que le processus de login est bien réalisé par une personne et non un bot. Il peut s’agir d’une réponse à une question secrète, le renseignement d’un code reçu par SMS, ou de répondre à un test Captcha. D’autres mesures simples (politique de mots de passe forts, messages d’erreur génériques, consultation régulière des journaux de logs, etc.), une sensibilisation continue et des formations sur la sécurité web, sont de bons moyens de se prémunir contre ce type d’attaque. Gestion des droits d’accès et élévation de privilèges Les utilisateurs d’une application sont censés être dignes de confiance et respecter les politiques de sécurité en place. Mais le sont-ils toujours ? Des utilisateurs légitimes ont de nombreuses raisons potentielles de devenir « malveillant » à certains moments :  Pour éviter une procédure qu’ils ne comprennent pas et qu’ils peuvent contourner, en utilisant une fonctionnalité à laquelle ils ne sont pas supposés avoir accès  Pour avoir accès aux données d’un autre utilisateur pour des raisons diverses  Pour accéder à des fonctionnalités réservées à un groupe d’utilisateurs, comme par exemple utiliser gratuitement des services payants La gestion des droits d’accès est un élément central dans la sécurité des applications web. C’est sûrement l’aspect le plus ciblé par des attaquants malveillants, souhaitant « élever leurs privilèges » pour parvenir à leurs fins. On parle en effet d’élévation de privilèges lorsqu’un utilisateur exploite une faille, un défaut de conception ou une erreur de configuration dans une application pour obtenir un accès élevé à des ressources qui devraient normalement lui être inaccessibles. Il peut alors utiliser les privilèges nouvellement acquis pour voler des données confidentielles, exécuter des commandes administratives ou déployer des logiciels malveillants ; et potentiellement causer de graves dommages à votre système d’information et votre image de marque. Généralement, les attaquants commencent par exploiter une vulnérabilité au niveau des droits d’accès dans un système ou une application cible, ce qui leur permet de passer outre les limitations du compte utilisateur actuel. Ils peuvent ensuite accéder aux fonctionnalités et aux données d’un autre utilisateur. Puis leur objectif consistera à obtenir des privilèges élevés, généralement ceux d’un administrateur (le Graal !) ou d’un autre utilisateur puissant. Un exemple concret que nous avons réalisé dans le cadre d’un test d’intrusion en boite grise sur une application SaaS :  Accès à un compte utilisateur standard dans l’environnement de production, avec des actions limitées au sein du back-office : consultation de documents, envoi de demandes de divers types via système de workflows, etc.  Grâce à un bug dans le back-office lié aux paramètres d’URLs, il a été possible d’accéder à des fonctionnalités disponibles à l’équipe support uniquement, ayant notamment la possibilité de mettre à jour les adresses email de tous les autres utilisateurs de la solution (dont les personnes disposant de droits super admin sur le back-office)  Ces fonctionnalités de l’équipe support nouvellement acquises, il a été possible de modifier l’email d’un super admin et de réinitialiser le mot de passe via la notification email reçu en ce sens Heureusement, cette vulnérabilité critique a été découverte dans le cadre d’un test d’intrusion. Nul besoin de préciser en quoi les conséquences auraient été désastreuses pour l’entreprise si jamais une attaque de ce type était survenue. Les applications constituent le point d’entrée le plus facile pour toute attaque, il est donc vital de les sécuriser : implémenter les meilleures pratiques de développement pour éviter les erreurs de programmation et de configuration, utiliser des scanners de vulnérabilité pour vérifier si vos applications sont faillibles, et réaliser des tests d’intrusion pour assurer que les niveaux de droits implémentés sont bien segmentés et cloisonnés. TÉLÉCHARGEZ NOTRE CAS CLIENT ÉDITEUR DE LOGICIEL Exploitation de failles XSS Supposons que la porte du back-office d’une application web soit solide, et son enceinte protégée par des remparts impénétrables. Les attaquants « irréductibles » se tourneront alors vers le front-office pour essayer d’injecter du contenu malveillant dans l’application via n’importe quel champ ou système d’envoi de données disponible. Le Cross Site Scripting (abrégé XSS) est une vulnérabilité courante des applications web qui, bien exploitée, peut uploads/Management/ app-web.pdf