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

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 :

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 :

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 :

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 :

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...

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 :

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.

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...

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.

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 :

Même...

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 :

2. Scénarios

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

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 :

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...

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 :

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 :

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 :

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 :

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 :

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 :

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)....