Connaitre les principales failles présentes dans les applications ?

Par Vincent , le mars 28, 2023 , mis à jour le mars 28, 2023 - 13 minutes de lecture
illustration failles applications

Les applications web ou mobiles ne sont pas à l’abri des cyberattaques. Or, beaucoup d’applications web manipulent des données sensibles (personnelles ou professionnelles) comme les mots de passe, les numéros de carte bancaire, des adresses e-mails, etc. Ainsi, les failles présentes dans ces applications compromettent inévitablement la sécurité des informations. D’où l’intérêt de les connaître afin de pouvoir prendre des mesures de protection.

Failles applicatives : qu’est-ce que c’est ?

Les failles applicatives sont celles qui visent directement vos applications web ou mobiles. Elles sont exploitées par les attaquants et les répercussions sur le système ou sur vos données et vos appareils peuvent être conséquentes.

Les conséquences les plus courantes d’une exploitation malveillante sont les vols d’informations et le piratage de votre appareil ou de votre système. Mais en prenant d’ampleur, l’exploitation des failles applicatives peuvent mener jusqu’à une prise de contrôle totale du système. Dans ce cas, l’application ne répond plus à votre commande et les attaquants disposent d’un champ libre pour consulter ou prendre les informations qui les intéressent.

Les programmeurs mettent tout en œuvre pour sécuriser les applications, mais les cyber attaquants s’améliorent eux aussi. Donc, la règle d’or que tous les programmeurs doivent appliquer, c’est d’éviter de faire confiance aux entrées utilisateurs en créant un programme. Il est crucial de vérifier minutieusement les données manipulées pour éviter qu’une grande quantité d’informations soit écrite dans un tampon.

Quels sont les types d’attaques qui menacent la sécurité des applications ?

Les attaques susceptibles de corrompre la sécurité des applications web sont regroupées en six catégories. Plus vous découvrez les vulnérabilités à temps, moins les conséquences de l’attaque seront graves.

La catégorie authentification

C’est le type d’attaque le plus fréquent, puisqu’il cible le système de validation de l’identité. Il peut s’agir d’une validation d’identité d’utilisateur, de service ou d’une application.

Pour forcer les systèmes d’authentification, l’attaquant privilégie souvent l’attaque par force brute. Grâce à des outils spécifiques, il inonde la page d’authentification de valeurs d’identifiants et de mot de passe. Finalement, il obtient l’accès direct à l’application et commence à prendre son contrôle.

La catégorie autorisation

Cette catégorie regroupe les attaques qui ciblent le système de vérification des droits. On parle ici des droits d’un utilisateur, d’un service ou d’une application pour effectuer une action avec ou dans cette application.

Ce type de menace est très dangereux, puisqu’il permet aux attaquants d’accéder à des données sensibles à travers les applications. La meilleure chose à faire est de limiter les autorisations qu’on accorde à nos applications. Sachez que beaucoup d’applications vous demandent l’autorisation d’accéder à vos contacts, à votre micro ou à votre caméra pour fonctionner, et c’est logique. Mais dès que les demandes deviennent plus inhabituelles ou incohérentes, il est fortement conseillé de renoncer à accorder une autorisation.

La catégorie “attaques côté client”

L’attaque côté client ou « client side » vise l’utilisateur au moment où il se sert de l’application. Les attaquants exploitent les failles applicatives dans le but de voler des données ou de prendre le contrôle des appareils infectés.

La catégorie exécution de commande

Cette catégorie regroupe toutes les attaques qui permettent d’exécuter des commandes sur un composant de l’architecture du site. Cette attaque peut engendrer des méfaits graves incluant : la corruption d’un fichier, le surcharge puis plantage du système, la création d’une porte dérobée, la récupération d’un fichier, etc.

La catégorie révélation d’information

Cette catégorie regroupe toutes les tentatives de chercher et de découvrir des informations ou des fonctionnalités cachées. Si ces dernières sont masquées, c’est sûrement pour une bonne raison. Soit il s’agit d’informations ou de fonctionnalités confidentielles, soit ce sont des données sensibles.

Avec une telle attaque, des informations importantes et secrètes peuvent atterrir entre de mauvaises mains. Les attaquants peuvent les vendre ou les utiliser dans le but de nuire aux propriétaires.

La catégorie “attaques logiques”

Ce sont les attaques qui utilisent les processus applicatifs à des fins hostiles. Les attaquants peuvent servir, par exemple, du système de changement de mot de passe ou du système de création de compte pour hacker le système ou le réseau.

Quels sont les principaux risques de sécurité qui pèsent sur les applications ?

Il existe sûrement des multitudes de menaces qui planent sur la sécurité des applications étant donné que les hackers ne cessent de se performer. Toutefois, il y a des risques plus évidents et plus courants et l’OWASP (Open Web Application Project) en recense dix.

La faille d’injection

C’est quand l’attaquant exploite les failles applicatives pour envoyer des données hostiles. Ces données mènent l’interpréteur à exécuter des commandes ou à accéder à des données non autorisées.

Cette faille est également appelée SQL injection ou SQLi. Plus concrètement, l’attaquant injecte du code SQL malveillant dans une requête. Ce code modifie forcément l’effet escompté et il compromet l’intégrité des données qui se trouvent dans la base. La faille SQL injection ou SQLi est un type de menace fréquemment utilisé pour contourner les systèmes d’authentification et d’autorisation d’une application.

Les conséquences d’une attaque par injection peuvent être lourdes, car les hackers auront accès à des données sensibles. Ils peuvent s’introduire dans la base de données et apporter des modifications non autorisées (ajouts ou suppressions de données ou exécution de code malveillant).

Si l’attaque par injection est si dangereuse, alors comment s’en protéger ? La meilleure solution est d’utiliser un système de requêtes préparées (PDO pour PHP, etc.). Le principe est simple : la requête est compilée avant d’être exécutée. Ainsi, vous serez sûrs qu’elle ne contient aucun caractère d’échappement.

Les failles de Cross-Site Scripting  (XSS)

Les types d’attaques XSS font partie de la catégorie des vulnérabilités par injection de code. La différence, c’est que pour s’y prendre, l’attaquant doit injecter le code malveillant depuis les paramètres d’entrée côté client.

Les objectifs d’une telle attaque sont multiples, mais souvent elle sert à détourner la logique d’une application. Ainsi, les hackers peuvent altérer des données ou des contenus, voler des cookies ou des jetons de sessions, exécuter un malware, la possibilité est quasi illimitée. Cela car l’attaquant est en mesure de contrôler le navigateur web de la victime et exécuter toutes les actions qui l’enchantent.

Les conséquences d’une telle attaque sont lourdes, mais en plus, certaines d’entre elles sont irréversibles.

Les attaques XSS se déclinent en trois types dont :

  • stored XSS (attaques XSS stockées)
  • les attaques XSS reflétées ou reflected XSS
  • les attaques XSS basées sur le DOM ou DOM-Based XSS

Pour les trois types d’attaques, le principe reste le même : utiliser des scripts malveillants entrés côté client et s’attendre à ce que ces scripts soient interprétés sur le navigateur cible.

Lors des attaques XSS stockées, le code malveillant se stocke sur le serveur et tout utilisateur qui visite la page peut être attaqué via son navigateur. C’est pour cela que cette attaque est considérée comme la plus dangereuse, puisqu’il ne faut qu’une seule injection de code malveillant pour toucher plusieurs utilisateurs.

En cas d’attaques XSS reflétées, le script malveillant est renvoyé dans le serveur. Le hacker peut utiliser l’e-mail de phishing, le système de chat ou les messages privés sur les réseaux comme relais pour l’attaque dans le but de forcer un clic sur le lien. En cas de clic, le script malveillant est envoyé au serveur et le code est envoyé en réponse à l’utilisateur.

Les attaques XSS basées sur le DOM sont aussi exécutées côté client. Mais au lieu d’utiliser le serveur, ces attaques se servent directement du navigateur de l’utilisateur. Ce genre d’attaque permet ainsi de modifier la structure du DOM (Document Object Model) et de voler des données.

Pour se protéger des attaques XSS, vigilance s’impose surtout quand on traite des données venant de l’extérieur. Il est fortement conseillé de filtrer, de valider et d’encoder chaque contenu avant d’être utilisé par l’application.

La violation de gestion d’authentification et de session

Une telle attaque permet au hacker de contourner ou de saisir les méthodes d’authentification qu’utilise une application. Elle exploite les vulnérabilités qui facilitent l’usurpation d’identité. Cette attaque est favorisée par un défaut de conception lors de la création d’une application. Elle se passe aussi en cas d’un manque de chiffrement réseau ou de mots de passe solides.

Ce genre d’attaques est surtout dangereux pour les utilisateurs, car les hackers s’attaquent à des données confidentielles et à leur vie privée. Une telle menace est également dangereuse pour les administrateurs des entreprises, puisque les attaquants peuvent accéder à des comptes non autorisés.

L’attaque par falsification de requête inter-sites (CSRF)

Le Cross-Site Request Forgery incite l’utilisateur à utiliser ses informations d’identification. Le but du hacker est d’invoquer une activité de changement d’état comme la modification d’une adresse e-mail, le transfert de fonds depuis un compte. Cette attaque engendre des dommages conséquents pour un simple utilisateur, mais elle est encore plus dangereuse pour un compte administratif.

L’attaque par falsification de requête inter-site peut compromettre un serveur entier. Si c’est le cas, alors le hacker prend le contrôle de l’application, de l’API ou d’autres services sensibles.

La méthode la plus courante pour atténuer les attaques CSRF est d’implémenter des jetons Anti-CSRF. Ce n’est pas une solution miracle, certes, mais elle permet d’amoindrir la chance des attaquants et de gagner du temps pour se rendre compte de l’attaque et de s’en protéger.

La faille causée par une mauvaise configuration de sécurité

Les serveurs d’application et les serveurs de base de données sont très vulnérables quand ils n’ont pas de configuration sécurisée correctement établie et déployée. Sachez que les paramètres et les configurations doivent être mis en œuvre, définis et bien maintenus. Toutes les bibliothèques de code que l’application emploie nécessitent toujours une mise à jour complète et régulière.

La faille de stockage de données cryptographique non sécurisée

Cette attaque regroupe toutes les faiblesses concernant la protection du stockage des données. D’où l’intérêt de mettre en place un chiffrement des informations. Grâce au chiffrement, l’information est incompréhensible à tout utilisateur qui ne possède pas la clé.

Sachez que les hackers s’attaquent souvent à des données sensibles, des informations dont la divulgation porte préjudice aux propriétaires. C’est le cas d’un mot de passe ou d’un identifiant de session. Ainsi, il est crucial d’éviter l’utilisation d’un algorithme de chiffrement ou de hachage assez faible comme MD5 ou SHA1. De même, il est fortement déconseillé de créer son propre algorithme.

La défaillance dans la restriction des accès à un URL

Une telle attaque se produit dans le cas où l’application Web ne protège pas l’accès aux URL. Par conséquent, un utilisateur non habilité dispose d’un accès à des fonctionnalités de l’application ou à des fichiers ou à des répertoires du serveur. Le souci, c’est que ces données sont sûrement sensibles et ne doivent pas tomber entre de mauvaises mains.

La meilleure méthode pour se protéger des défaillances dans la restriction des accès à un URL est de ne jamais autoriser les caractères douteux. Dressez une liste de fichiers utilisables et refusez tout autre fichier douteux ! C’est le meilleur moyen de se prémunir des attaques par traversée de chemin. Chaque répertoire doit aussi contenir un fichier index.html afin d’interdire l’accès.

Protection insuffisante ou faible de la couche transport

L’attaque se produit dans le cas où cette application n’est pas en mesure de chiffrer et de protéger la confidentialité du trafic réseau. Sachez qu’une requête ou une réponse http peut être interceptée. Si elles contiennent des données confidentielles, alors l’attaquant sera en mesure de les consulter et de les utiliser.

L’ensemble du réseau de l’architecture de l’application est concerné par cette menace, à commencer par le navigateur de l’utilisateur. Le serveur web et le stockage de données ne sont pas épargnés.

Les dangers liés à la redirection et au renvoie non validés

Elle se produit dans le cas où l’utilisateur est redirigé vers d’autres pages ou vers d’autres sites. Le risque d’attaque est très élevé si on utilise des données non fiables pour déterminer la page de destination.

En cas d’absence d’une validation appropriée, les utilisateurs peuvent être orientés vers des sites de phishing ou vers un logiciel malveillant. Cette faille permet aussi aux attaquants d’accéder à des pages non autorisées grâce au renvoi. Dans un cas comme dans un autre, la sécurité des utilisateurs est sérieusement compromise.

Vincent

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.