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
[email protected]
 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 permettre de voler une session, remplacer une partie de
l’interface utilisateur, télécharger des logiciels malveillants [etc.] via de l’injection de
code (JavaScript, HTML, CSS). Il existe 2 types d’attaques XSS :

 Les attaques XSS stockées (stored XSS attacks) qui envoient un

contenu malicieux sur le serveur hébergeant une application web, afin qu’il
soit renvoyé dans le navigateur des utilisateurs.  
 Les attaques XSS reflétées (reflected XSS attacks) qui ne stockent pas
le contenu malicieux sur le serveur web, mais qui le livrent aux utilisateurs
de l’application via une URL ou directement sur le navigateur.
En somme, les attaques XSS reposent sur l’envoi de contenus malicieux affichés sur le
navigateur des utilisateurs d’une application web, sous forme de pop-up ou une
redirection vers un site externe.

Il est difficile de détailler toutes les conséquences possibles des attaques XSS, la liste
serait très longue. Pour s’en protéger, il faut partir du principe que les données reçues
par une application web ne peuvent pas être considérées comme « toujours » sûres. Il
est important de suivre des règles strictes pour traiter les données venant de l’extérieur.
Tout contenu doit être nettoyé, validé et/ou encodé avant d’être utilisé par
l’application. Les scanners de vulnérabilités peuvent repérer certaines de ces
vulnérabilités, mais un test d’intrusion ou une revue de code seront plus complets.

Les attaques par injection SQL

Les attaques par injection sont facilitées par le fonctionnement même des applications
web, car elles ont besoin de données pour fonctionner. Et plus il faut de données, plus
les opportunités d’attaques par injection sont nombreuses.

Une vulnérabilité courante : les failles d’injection SQL ; qui permettent d’interagir
avec la base de données d’une application par le biais de requêtes non-prévues. Ces
failles peuvent conduire à des vols, pertes de données, une suppression ou une
manipulation des données stockées.

Sécurité des systèmes interconnectés

Les applications web sont souvent reliées à des services ou systèmes tiers, notamment
pour faire communiquer des données. La plupart des FinTech utilisent par exemple des
systèmes de paiement, développés et commercialisés par des tiers, pour les intégrer à
leurs applications web maison. Ces systèmes de paiement sont généralement sécurisés
car il existe de nombreux standards en matière de sécurité dans le domaine du
paiement électronique, notamment PCI-DSS.

Vous l’aurez compris, une application tierce peut être robuste sur le plan de la sécurité,
mais des vulnérabilités apparaissent très souvent en raison d’un problème de
configuration et/ou d’implémentation du système d’interconnexion (web services,
APIs : nous reviendrons plus en détail sur les failles courantes et les bonnes pratiques
de sécurité des APIs dans notre prochain article).  

TÉLÉCHARGEZ NOTRE CAS CLIENT FINTECH

Sécurité des composants tiers
Les composants tiers sont un des points d’attraction 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évelopper plus rapidement et plus
facilement des applications, et ce, en tirant parti de l’appui d’une communauté active.
Cependant, ces composants tiers sont exposés à des attaques web. Et pour ne pas
arranger les choses, plus un composant est populaire, plus il est l’objet d’attaques. En
effet, lorsqu’une faille de sécurité est découverte sur un composant, elle devient
souvent publique.

La solution : un patch est développé afin de corriger cette faille dans la nouvelle
version, qui sera « normalement » installée par les développeurs utilisant ces
composants tiers. Le problème : les attaquants attendent également les mises à jour
contenant les détails des vulnérabilités découvertes, afin de lancer rapidement des
attaques sur des composants critiques.

Les possibilités de failles sont, comme sur toute autre application, nombreuses
(injections, XSS, failles d’authentification, etc.). Un exemple rencontré dans le cadre
d’un test d’intrusion en boite grise sur une application SaaS permettant la gestion de
données financières d’entreprises :

 Plateforme fermée du point de vue d’un attaquant externe, seul un

formulaire d’authentification était accessible
 Après des tests approfondis et des recherches poussées en direction
des composants tiers utilisés, nous avons repéré une librairie javaScript
 La version installée étant ancienne, elle présentait une vulnérabilité
connue qui permettait notamment de lire n’importe quel fichier présent sur le
serveur l’hébergeant
 En l’exploitant, il a été possible d’extraire de nombreux fichiers
sensibles présents sur le serveur web, et d’accéder in fine à l’intégralité des
données gérées par la plateforme web.
Pour contrer ces attaques, nous conseillons de limiter au maximum l’utilisation de
composants tiers, si vous disposez des ressources permettant de s’en passer. Vous
aurez toujours plus la main sur la sécurité d’un développement-maison que d’un
composant externe.

Si cela n’est pas possible, il est important de maintenir à jour une liste des composants
tiers utilisés sur votre application web, et leurs versions. Cela facilitera l’identification
des composants vulnérables, et votre l’équipe de développement pourra agir si besoin,
en ayant une connaissance précise des éléments utilisés. Pour ce faire, il est conseillé
d’assurer une veille technique et technologique afin de surveiller les nouvelles
versions disponibles et les vulnérabilités découvertes sur les composants tiers utilisés.
S’inscrire à des mailing lists projets (celles des composants utilisés), ou des mailings
lists de sécurité sont autant de moyens de rester informé et sur le qui-vive.  
Au-delà des failles techniques, des failles logiques
souvent oubliées
Les vulnérabilités techniques sont inhérentes aux applications web. Au-delà de ces
vulnérabilités, il subsiste aussi des failles logiques qui, elles sont liées aux workflows,
et indétectables avec des outils automatiques (scanners et autres). Qu’est-ce qu’une
faille logique ?

Une faille logique existe lorsque le fonctionnement normal d’une application,

autrement dit une étape logique ou un processus prévu, peut être évité ou contourné.

Un exemple concret de faille logique découverte dans le cadre d’un test d’intrusion en
boite noire sur une plateforme e-commerce :  

 Création d’un compte pour effectuer des achats sur la plateforme

 Ajout de produits dans le panier puis passage à l’étape de validation
du panier
 Modification du prix des produits ajoutés au panier (sans changer
leurs références) en éditant directement le code HTML, ce qui a entrainé une
baisse de la valeur « affichée » de notre panier
 Enfin, il a été possible de valider le paiement de notre panier (à tarif
réduit), car le prix indiqué dans la requête de paiement envoyée à la banque
prenait comme référence le prix du panier affiché dans notre navigateur.    
Ceci a été possible car la plateforme n’effectuait pas de vérification et se fiait aux
entrées utilisateur. Afin de se prémunir, il est préférable que le serveur indique le prix
à payer à la banque en fonction de la référence des produits voulus. L’affichage du
prix coté utilisateur ne doit être qu’une indication visuelle pour lui-même et non une
valeur à prendre en compte.

En somme, les failles logiques sont généralement le résultat d’un défaut de conception
des applications web ou d’un manque de tests approfondis d’un point de vue sécurité.
Et si tests sécurité il y a, il est nécessaire de se focaliser sur ce que l’application n’est
pas supposée permettre pour détecter ses faiblesses logiques.

Pour ce faire, il est nécessaire de bien comprendre le comportement attendu de

l’application, la logique et les règles métiers, les contrôles sécurité qui en découlent, et
donc les potentiels abus fonctionnels, puis de faire preuve de créativité pour construire
des scénarios imprévus, et enfin les tester sur l’application.

TÉLÉCHARGEZ NOTRE CAS CLIENT E-COMMERCE

Réaliser des tests d’intrusion d’application
web pour évaluer et réduire les risques
sécurité  
Les tests d’intrusion d’application web sont la solution par excellence pour faire face
aux attaques informatiques. Ne dit-on pas que la meilleure défense, c’est l’attaque !
Cet adage résume parfaitement le principe des tests d’intrusion, qui consistent en effet
à tester la sécurité d’une application ou d’un autre système en réalisant diverses
attaques afin d’identifier des vulnérabilités techniques et logiques potentielles.  
Lors d’un test d’intrusion d’application web, trois approches sont possibles : des tests
en boite noire, des tests en boite grise ou des tests en boite blanche. Ces approches
correspondent à différents niveaux d’information et d’accès fournis aux pentesters. Les
tests d’intrusion en boite noire ciblent la surface d’attaque accessible à n’importe quel
attaquant externe, tandis que des tests d’intrusion en boite grise vont concerner des
éléments disponibles avec des accès fournis par le Client (et non accessibles
autrement). Un test d’intrusion en boite blanche quant à lui permet d’analyser le
niveau de sécurité en disposant de tout ou partie du code source de l’application et
d’un accès à l’infrastructure l’hébergeant.

Les tests d’intrusion d’application web permettent de rechercher des vulnérabilités

liées à la configuration des serveurs web ainsi que des vulnérabilités liées à la couche
applicative. Côté serveur, il s’agit par exemple de services ouverts et mal sécurisés, de
logiciels non à jour, ou d’erreurs de configuration. Et nous reviendrons sur ce point
dans notre prochain article. Côté applicatif, il s’agit des vulnérabilités répertoriées par
l’OWASP (les failles du top 10 dont certaines ont été abordées plus haut), ainsi que les
failles logiques.
Un rapport complet est remis suite à un test d’intrusion. Ce livrable inclut la
méthodologie employée, les vulnérabilités identifiées (classifiées par niveau de
criticité : faible, importante, critique), l’exploitation possible ainsi que des
recommandations de correction. Une présentation des résultats de l’audit, par le(s)
pentester(s) en charge de l’audit permet d’échanger sur les résultats de l’audit de
sécurité.

Chez Vaadata, nous démocratisons les tests d’intrusion avec des offres adaptées aux
startups comme aux grandes entreprises. Il est tout autant possible de réaliser un
premier test d’intrusion d’une journée à 675 euros (incluant rapport et présentation des
résultats), que de partir sur un audit plus en profondeur avec un budget compris entre
2500 et 10 000 euros (tarif déterminé en fonction de la complexité fonctionnelle et
technique et votre application web, ainsi que du niveau de profondeur souhaité).

Contactez-nous pour toute question relative à un projet de tests d’intrusion sur votre
application web. Nous échangerons sur vos besoins et vous proposerons une
intervention adaptée à vos enjeux sécurité et vos contraintes, qu’elles soient
budgétaires ou organisationnelles.
CONTACTEZ-NOUS

Articles en lien
Comment sensibiliser vos collaborateurs pour contrer les attaques d’ingénierie
sociale ?
6 MAI 2022

Comment sécuriser un réseau interne ?

25 AVRIL 2022

Comment renforcer la sécurité de vos APIs pour contrer les attaques les plus
courantes ?
20 AVRIL 2022

 Qui sommes-nous ?
Vaadata est une société spécialisée en pentest. Nous sommes passionnés par la sécurité, à la fois
pour ses défis techniques et pour ses enjeux de société.
 Langue

o Anglais

o Français
 TOUS NOS ARTICLES
 Catégories
o Actualités
o Marketing digital
o Risques
o Solutions
o Technique

 Articles récents
o Comment sensibiliser vos collaborateurs pour contrer les attaques d’ingénierie sociale ?
o Comment sécuriser un réseau interne ?
o Comment renforcer la sécurité de vos APIs pour contrer les attaques les plus courantes ?
 o Node.js : Failles fréquentes et bonnes pratiques sécurité
o Une vulnérabilité RCE dans un nom de fichier

 Rechercher
Search for:

 

©2022 VAADATA

 TOP

 VAADATA
 PENTEST
 CONSULTING & FORMATIONS
 VOS BESOINS
 LIVRES BLANCS & CAS CLIENTS
 CONTACT

Gestion des cookies

Nous utilisons des cookies pour vous fournir les services demandés et pour analyser l'audience de
notre site.
Consentements certifiés par
B