Blog ENI : Toute la veille numérique !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
💥 1 livre papier acheté 
= la version en ligne automatiquement offerte. Cliquez ici
  1. Livres et vidéos
  2. Sécurité informatique sur le Web
  3. Top 10 des risques et vulnérabilités liés au Web
Extrait - Sécurité informatique sur le Web Apprenez à sécuriser vos applications (management, cybersécurité, développement et opérationnel)
Extraits du livre
Sécurité informatique sur le Web Apprenez à sécuriser vos applications (management, cybersécurité, développement et opérationnel)
1 avis
Revenir à la page d'achat du livre

Top 10 des risques et vulnérabilités liés au Web

Le top 10 des menaces du Web

Maintenant que nous avons étudié les différents éléments de la sécurité web tels que les normes, les guides, les bonnes pratiques, les logiciels d’analyse de code, la sécurité des navigateurs et le serveur, il est temps d’étudier les risques actuellement rencontrés par les applications web sur Internet ou dans les systèmes d’informations des entreprises.

Chaque point abordé dans ce chapitre a pour ambition de former et sensibiliser un développeur aux risques, à la sécurisation du code et aux bonnes pratiques à appliquer en entreprise, mais pas seulement. Toute personne confronté de près ou de loin à la question de la sécurité des systèmes d’information (risk manager, RSSI, auditeur, etc.) doit être sensibilisée aux risques de la sécurité applicative afin de pouvoir par la suite établir un programme dans une organisation liée à la sécurité des applications.

Ce chapitre commencera par l’étude technique et l’exploitation des différentes menaces les plus présentes dans le monde du Web. Il est en effet courant de former les développeurs aux méthodes de piratage (hacking) utilisées par les cybercriminels afin de mieux comprendre les protections et les bonnes...

Comprendre les risques selon l’OWASP

L’OWASP et son top 10 que nous avons présentés lors du chapitre précédent (cf. Panorama de la sécurité web - Les guides et bonnes pratiques), vont être étudiés plus en détail dans cette section. Pour rappel, le top 10 est un document abordant les dix risques les plus rencontrés lors d’une attaque cybercriminelle. Pour arriver à ce résultat, l’OWASP réalise une enquête auprès des organisations ayant des statistiques sur les attaques rencontrées et regroupe le tout pour établir un classement des risques. Les éléments de classification sont :

Agents de menace

Correspondant à la description de l’attaquant (qui ?)

Vecteur d’attaque (exploitabilité)

Exploitabilité de la vulnérabilité (facile, moyenne, difficile)

Prévalence

La vulnérabilité est-elle courante (commune, répandue, très répandue) ?

Détectabilité

Est-il facile de détecter la vulnérabilité (facile, moyenne, difficile) ?

Impact technique

Quelles sont les conséquences et la finalité de l’exploitation de la vulnérabilité ?

Impact métier

Quel est l’impact (en termes de réputation, commercial, légal, juridique, etc.) ?

Il est important...

Installation de la plateforme de travail

Pour commencer à travailler, nous allons devoir virtualiser et installer un système d’exploitation (OS) spécifique et une application afin de disposer de tous les outils nécessaires pour nos tests de pénétration. Voici les différentes étapes :

 Téléchargez un logiciel de virtualisation (hyperviseur) compatible avec votre machine. Dans ce livre, nous avons fait le choix d’utiliser l’hyperviseur VirtualBox d’Oracle car il s’agit d’un hyperviseur stable, gratuit et dont l’interface est identique quel que soit le système d’exploitation utilisé (Windows, Mac, Linux). Celui-ci est en téléchargement à l’adresse suivante : https://www.virtualbox.org/wiki/Downloads

 Installez VirtualBox en suivant toutes les étapes et lancez celui-ci ; la console suivante doit apparaître.

Attention, si vous avez déjà un hyperviseur, il peut y avoir conflit.

images/03EP01.png

 Téléchargez l’image VirtualBox du système d’exploitation Kali Linux compatible avec votre système d’exploitation à cette adresse : https://www.offensive-security.com/kali-linux-vmware-virtualbox-image-download/ pour le téléchargement torrent ou ici : https://drive.google.com/drive/folders/0Bw4YT2Pzi6EeT3I0YzRNa0o1TXM?usp=sharing...

Les injections

1. Les risques

Le risque d’injection est placé au premier rang dans le classement OWASP TOP 10. L’impact technique et sa facilité d’exploitation sont, selon l’étude OWASP, à leur maximum. D’ailleurs, l’impact métier est généralement très critique car le risque est basé sur des supports primaires tels que les données utilisateur ou entreprise qui sont souvent confidentielles. Les dernières années n’ont pas été de tout repos pour les entreprises. Les fuites de données (leak) via injection de données sont devenues monnaie courante. Verizon avec 1,5 million de données utilisateurs, Yahoo! avec 500 millions de comptes utilisateurs et mots de passe, Sony PSN avec 7 millions de cartes de crédit, Vtech, Visa, Adobe, la liste est longue.

Voici un graphique présentant l’évaluation du risque selon l’OWASP :

images/03EP06.png

Il existe une multitude d’attaques par injection telles que LDAP, XPath, NoSQL, OS, etc. La plus connue est sûrement l’injection SQL, qui permet de tronquer des commandes SQL (Standard Query Language) utilisées par l’application web afin de récupérer le maximum d’informations provenant de bases de données.

2. Injection SQL

L’injection SQL (SQLI) est sûrement la plus populaire car la plupart des applications web utilisent des systèmes de gestion de base de données (SGBD, SGBDR) se servant du langage SQL (MySQL, MariaDB, Oracle, etc.). Pour rappel, voici un schéma simple de la relation entre une application web et un SGBD avec l’exemple d’une authentification :

images/03EP07.png

1.

L’utilisateur désire s’authentifier sur l’application et il remplit les champs avec ses identifiants qui sont envoyés à travers une requête POST HTTP au serveur web.

2.

Le serveur web réceptionne les identifiants pour les traiter et former une requête SQL du type SELECT * FROM compte WHERE id=admin AND password=P@$$w0rd. Cette requête cherche les identifiants admin/P@$$w0rd à l’intérieur des champs id/password de la table nommée compte.

3.

Le SGBD reçoit et interprète la requête envoyée par le serveur web, puis recherche à l’intérieur...

Violation de gestion d’authentification et de session

1. Présentation et risques

La violation de session et d’authentification permet à un cybercriminel de capturer ou contourner les méthodes d’authentification utilisées par une application web.

Les attaques de ce type sont dues à des défauts de conception lors de la création de l’application ou au manque de chiffrement réseau ou des mots de passe.

Les risques d’une telle attaque sont importants car elle touche directement à la protection des données des utilisateurs et à leur vie privée mais aussi aux administrateurs des entreprises avec le risque que des cybercriminels accèdent à des comptes non autorisés. Voici l’évaluation du risque par l’OWASP :

images/03EP32.png

Le graphique ci-dessus montre bien la criticité du risque et justifie pleinement le placement de celui-ci au deuxième rang du top 10 OWASP.

2. Vol de session (session hijacking)

Pour comprendre comment fonctionne le vol de session et s’en protéger, il est nécessaire de faire un rappel sur le fonctionnement d’une session dans une application web :

  • À l’aide d’un formulaire sur le site web, l’utilisateur s’authentifie avec un identifiant et un mot de passe.

  • Les informations sont soumises à l’application qui crée un identifiant de session, qui suivra l’utilisateur tout au long de sa navigation sur le site web. L’identifiant est généralement stocké dans un cookie et peut être supprimé une fois que l’utilisateur se déconnecte manuellement du site par un bouton Déconnexion mis à disposition ou par un dépassement de durée de vie de la session.

La méthode de l’homme du milieu (MITM), déjà présentée dans le chapitre précédent (cf. Panorama de la sécurité web - La sécurité des navigateurs et serveurs web), est très efficace pour le vol de sessions. Toute connexion HTTP sans système de chiffrement laisse passer en clair les identifiants et mots de passe ainsi que les identifiants de session demandés par le serveur lors de chaque requête HTTP par le client, ce qui laisse les applications web sans connexion HTTPS sensibles...

Cross-Site Scripting (XSS)

1. Présentation et risques

La troisième place du classement OWASP TOP 10 est attribuée au Cross-Site Scripting qui a pour particularité d’être le seul risque du TOP 10 ayant comme indice de prévalence "très répandu". Effectivement, d’après une étude de l’éditeur Egdescan, 52 % des applications web seraient sujettes au XSS en 2015.

Malgré les protections sur les navigateurs, les pare-feu applicatifs (WAF) et les outils d’analyses de code, les XSS restent une vraie source de menaces pour les utilisateurs. Voici d’après l’OWASP l’évaluation du risque lié au XSS :

images/03EP40.png

Le XSS permet à un cybercriminel d’envoyer du code JavaScript à l’aide d’une entrée utilisateur (formulaire, en-tête HTTP, query string, etc.) mal protégée, afin de récupérer des identifiants de sessions, de hameçonner, d’enregistrer les touches frappées par l’utilisateur, etc. Dans cette section, les trois types de XSS sont présentés.

2. XSS stocké (stored)

Le XSS stocké est sûrement la vulnérabilité la plus simple à exploiter, la plus dangereuse des trois XSS mais aussi la plus rare. Pour autant, le CMS le plus répandu au monde, WordPress, a été sujet à une vulnérabilité XSS stored en 2015 dans le coeur même du CMS. Il est donc indispensable de connaître les fondamentaux afin de s’en prémunir par la suite.

À la différence des autres XSS, le XSS stocké est comme son nom l’indique, stocké de façon permanente dans l’application web, ce qui le rend permanent et redoutable pour l’utilisateur. En effet, le vol de cookies (session hijacking), l’enregistrement de frappes (keylogger) et le hameçonnage peuvent être maniés facilement une fois un XSS stored identifié et inséré dans une application par un cybercriminel.

images/03EP41.png

Rien de mieux qu’un exemple pour comprendre la vulnérabilité et corriger celle-ci.

Le scénario est le suivant.

Le cybercriminel prépare un serveur ou utilise une solution sur Internet pour intercepter les données qui seront volées...

Références directes non sécurisées à un objet

1. Présentation et risques

Les références directes non sécurisées à un objet sont des vulnérabilités s’attaquant à la mauvaise gestion des droits et d’identification dans une application. Chaque site web contenant des données dynamiques comme un back-office pour l’administration en arrière-plan d’une application, doit être pourvu de rôles d’utilisateurs, d’administrateurs ou de modérateurs suivant les besoins de l’application. Si une référence à un objet n’est pas contrôlée à chaque instanciation de celui-ci, un cybercriminel pourrait donc obtenir et modifier des informations auxquelles il ne devrait pas avoir accès.

Une vulnérabilité du type Références directes non sécurisées a été découverte sur YouTube par un chercheur en sécurité russe nommé Kamil Hismatullin en 2015. Celui-ci pouvait détruire n’importe quelle vidéo en modifiant l’identifiant de la vidéo lors de la demande de suppression sur sa page YouTube.

images/03EP53.png

Même si l’identifiant de la vidéo ne lui appartenait pas, la vidéo était supprimée car la vérification de l’utilisateur n’était pas faite. Bien sûr, il n’y a pas un seul exemple d’exploitation pour ce genre de vulnérabilités. Suivant l’architecture de l’application des multiples scénarios sont possibles.

Voici d’après l’OWASP l’évaluation des risques :

images/03EP54.png

Même...

Mauvaise configuration de sécurité

1. Présentation et risques

La mauvaise configuration des éléments de sécurité arrive en cinquième position du classement OWASP TOP 10. Le périmètre d’une mauvaise configuration de sécurité peut dépasser le périmètre d’une application. La mise à jour des serveurs web, des librairies, des comptes administrateur inactifs, l’affichage des messages d’erreurs... sont des vulnérabilités associées à ce risque. Le principe des moindres privilèges, la sécurité par défaut, la défense en profondeur et la réduction des surfaces d’attaque aident à se protéger de ces risques et seront étudiés dans le prochain chapitre en détail.

Regardons l’évaluation des menaces suivant l’OWASP :

images/03EP56.png

2. Scénarios

De façon à comprendre le risque, voici une liste de scénarios possibles :

  • Le cybercriminel provoque une erreur sur l’application, ce qui lui permet d’obtenir des informations importantes pour corrompre l’application.

  • Le serveur hébergeant l’application a des utilisateurs et mots de passe par défaut sur les services SQL, SSH, FTP, Apache, IIS, etc.

  • Une application faite avec un framework est "poussée" en production mais...

Exposition de données sensibles

1. Présentation et risques

L’exposition de données sensibles concerne surtout les attaques cryptographiques, voire le manque de chiffrement sur les réseaux et données stockées. Comme vu dans le chapitre précédent (cf. Panorama de la sécurité web - La sécurité des navigateurs et serveurs web), les attaques du type homme du milieu (MITM) sont assez simples à mettre en place et efficaces si l’application n’utilise pas de chiffrement SSL/TLS avec un HSTS (Strict Transport Security) bien configuré. La confusion entre les protocoles de chiffrement, le hachage et l’encodage peut créer des brèches, par exemple l’utilisation de fonctions base64 pour traiter des données sensibles au lieu d’un chiffrement. Ci-dessous, l’évaluation des risques selon l’OWASP :

images/03EP57.png

Selon l’OWASP, la prévalence et l’exploitabilité de ce risque sont faibles. En revanche, l’impact technique, quant à lui, est sévère, et c’est pour cette raison qu’il faut prendre en compte ce risque, surtout dans le cas où des exigences en termes de confidentialité et d’intégrité sont présentes.

Tout comme la présentation du risque précédent sur les mauvaises configurations de sécurité, la présentation...

Manque de contrôle d’accès au niveau fonctionnel

1. Présentation et risques

Le manque de contrôle d’accès est un risque lié à des vulnérabilités retrouvées dans la gestion des droits d’une application, des défauts de conception ou l’utilisation de fonctions appropriées à l’intérieur du code. L’attaquant peut alors accéder à des fonctionnalités non autorisées, voire compromettre le site, avec des attaques du type déni de service (DoS, DDoS). Voici l’évaluation du risque selon l’OWASP :

images/03EP58.png

L’exploitabilité d’un tel risque pour un attaquant, la prévalence, la détection et son impact technique peuvent s’avérer modérés selon l’OWASP.

2. Local/remote file inclusion

Les local/remote file inclusion (LFI/RFI) rapidement présentés lors de la section sur le risque 2 du top 10 OWASP sur la violation de gestion d’authentification et de session est une vulnérabilité bien connue du monde de la cybersécurité. Pour rappel, ces vulnérabilités exploitent une mauvaise conception dans le code utilisant des fonctions de type include() en PHP ayant par exemple pour utilité d’inclure une autre page web à l’intérieur de la page actuellement consultée. Voici un exemple de code vulnérable :


<?php 
   $itemMenu = $_GET['menu']; 
   if(isset($itemMenu)) 
   { 
       include("pages/$ItemMenu");   
   } 
 
   ?>
 

Ce code laisse la possibilité à un utilisateur d’envoyer au serveur web une référence à une page demandée sur le serveur, tel un menu. La faiblesse dans ce type de conception de code est qu’un cybercriminel pourrait modifier la requête envoyée au serveur avec une demande autre que l’item d’un menu, par exemple un fichier en local (LFI) ou sur un autre serveur (RFI). Voici un exemple de scénario avec l’application bWAPP :

 Sur l’application bWAPP (http://localhost/securiteWEB/bWAPP), sélectionnez dans le menu la page Remote & Local File Inclusion (RFI/LFI).

 Un menu apparaît sur la page avec...

Cross Site Request Forgery (CSRF)

1. Présentation et risques

Les vulnérabilités de type Cross Site Request Forgery peuvent s’apparenter aux vulnérabilités du type SSRF vu précédemment mais côté client. De plus en plus présentes sur le Web, elles permettent de forcer l’utilisateur à envoyer une requête HTTP à son insu afin de changer son mot de passe, acheter sur un site marchand ou le déconnecter d’une application.

Voici un scénario type d’une attaque CSRF :

images/03EP67.png

L’attaquant envoie un e-mail à un utilisateur avec un lien malicieux mais pouvant passer inaperçu. Ce lien renvoie vers un serveur hébergeant un script JavaScript dont le but est d’envoyer un formulaire HTML au serveur web pour changer le mot de passe de l’utilisateur.

Ci-dessous, l’évaluation du risque selon l’OWASP :

images/03EP68.png

La détection d’une telle attaque sur une application web est relativement simple, les autres métriques sont modérées.

2. CSRF et requête POST

Voici un exemple de scénario avec l’application bWAPP :

 Accédez à la page Cross Site Request Forgery (Transfert Amount) de bWAPP. L’application présente un formulaire ressemblant à un transfert d’argent sur un site bancaire, pour une somme de 1 000 euros.

images/03EP69.png

 À l’aide...

Exploitation de vulnérabilités connues

1. Présentation et risques

Le risque d’exploitation de vulnérabilités connues ne s’adresse pas seulement au périmètre du code mais à toute l’infrastructure d’une application comme les services web, les frameworks, les systèmes d’exploitation... Chaque année, de nouvelles vulnérabilités avec un impact sur des millions de systèmes sont dévoilées. Une des dernières fut Heartbleed, qui a impacté 17 % des serveurs web dits sécurisés par le protocole TLS, dont Amazon Web Services, GitHub, Reddit, etc. Cette vulnérabilité autorise un cybercriminel à obtenir des informations en transit sur le serveur et ainsi voler les cookies, les sessions, les mots de passe des utilisateurs naviguant sur l’application. Heartbleed est simplement un exemple, chaque année des vulnérabilités de ce type sont divulguées ou pas. En effet, il existe des vulnérabilités dites « 0day », c’est-à-dire qu’elles ne sont pas connues, voire en vente sur le marché noir.

Voici l’évaluation des risques sur l’exploitation de vulnérabilités connues :

images/03EP71.png

L’OWASP décrit le risque avec une prévalence très forte mais une détection faible car c’est souvent dans le domaine de la recherche que ce type de vulnérabilités est trouvé. Des sites web tels qu’Exploit-db.com, OSVDB ou les blogs de CERT (Computer Emergency Response Teams) répertorient les vulnérabilités et les faiblesses par des CVE/CWE, déjà étudiées dans le chapitre précédent (cf. Panorama de la sécurité web - Les bibliothèques, projets et recommandations)....

Redirections et renvois non validés

Les redirections et les renvois non validés sont une vulnérabilité profitant d’une faiblesse dans le code et dont l’objectif est de rediriger l’utilisateur sur une page malveillante ou administrative du site web. Il est courant de voir des redirections d’URL interne sur la plupart des applications utilisant un modèle MVC (Model View Controller). Globalement bien configuré dans la plupart des frameworks, il peut s’avérer que certaines applications "from scratch" sont vulnérables et permettent à un attaquant de contourner les contrôles d’accès ou de rediriger vers une page de phishing suivant le cas.

Voici selon l’évaluation du risque selon l’OWASP :

images/03EP76.png

Même si la détection est simple pour ce type de vulnérabilités, la prévalence reste basse.

Voici un scénario type :

 Sur l’application bWAPP, dirigez-vous vers la page : Unvalidated Redirects & Forwards(2).

 La page s’affiche avec un lien Click here to go back to the portal. À l’aide d’un clic droit sur le lien, sélectionnez l’option proposée Copy Link Location.

 Copiez ensuite le lien dans la barre d’adresse ; l’URL suivante s’affiche : http://localhost/securiteWEB/bWAPP/unvalidated_redir_fwd_2.php? ReturnUrl=portal.php...