Filtrer le trafic vers une application web se résume généralement aujourd’hui à l’utilisation de listes blanches et de listes noires, bloquant ou autorisant des chaines de caractères.

Des mécanismes plus avancés permettent de corréler les différentes détections de données suspectes pour bloquer ou non les requêtes.

Pour aller plus loin dans la protection, il est nécessaire de surveiller la session utilisateur, et pas seulement l’aspect cookie et session applicative permettant d’identifier une personne, mais de façon plus globale, la logique et le comportement normal d’une application tout au long de la navigation de l’utilisateur. Ceci passe par l’analyse des flux entrants et sortants.

Il devient dès lors nécessaire de comprendre les différents points d’entrée, les différents chemins de navigation possibles, les types et volumes de données qui composent les réponses aux requêtes reçues par l’application web.

Par exemple, un utilisateur normal sur un site de e-banking s’identifiera sur un script de login et ira visualiser ses dernières transactions bancaires, qui sont affichées par pages de 50 lignes. Il est donc peu probable qu’il soit amené à recevoir en retour des pages comportant plusieurs milliers de lignes…

Requêtes et réponses

Il convient donc de s’attacher principalement à la surveillance de deux types de critères d’analyse :

Les requêtes passées au serveur ou à l’application Web  :

• la ressource demandée par l’utilisateur,
• les différents paramètres qu’il peut fournir,
• les informations de session.

Les réponses renvoyées:

• le code retour du serveur,
• la structure des données,
• le volume des données,
• la présence de données sensibles (numéro de carte bancaire, de sécurité sociale, etc.)

Demande…

La requête appelle une ressource avec différentes informations permettant le plus souvent une génération de contenu dynamique renvoyé par le serveur dans la « réponse ».

La requête en tant qu’action est déjà analysée par les mécanismes classiques, c’est la requête dans le contexte de navigation qui nous intéresse ici.

Selon l’état de la navigation, l’appel à une ressource ou à une autre peut déterminer si l’utilisateur suit un chemin normal dans son utilisation de l’application. Une utilisation hors chemin d’une ressource peut indiquer que l’utilisateur s’est servi d’un signet pour accéder à une page, ou qu’il tente directement d’accéder à une ressource pour laquelle il n’aurait pas les autorisations.

Le contenu des variables GET ou POST transmises à l’application est important, mais est déjà filtré contre les attaques classiques par les listes noires. Dans le cas de l’analyse du contexte global, il est important de se focaliser sur le contenu de ces variables, leur présence ou non dans le contexte de navigation. L’accès à une ressource sans les variables nécessaires à son bon fonctionnement peut révéler une tentative d’utilisation détournée de celle-ci.

Les informations de session permettent de déterminer les différents droits que pourrait avoir un utilisateur sur les différentes parties de l’application. La tentative d’accès à une ressource sans informations de sessions, avec des informations de sessions erronées ou ne correspondant pas au type de client et IP source qui les a générées peuvent cacher une tentative d’usurpation d’identité.

Il te sera répondu…

La réponse est le résultat de l’appel à une ressource et des différents paramètres qui lui ont été fournis.

Ces différents paramètres peuvent être fournis lors de la requête, mais auront pu être stockés dans le contexte de navigation lors de requêtes précédentes.

Le code retour serveur peut indiquer un dysfonctionnement momentané du serveur web en raison d’une requête mal formée. La détection de type liste noire à des limites et une requête qui peut paraitre normale peut en fait créer un dysfonctionnement sur le serveur.

Par exemple, le fait qu’une variable soit manquante peut déclencher l’arrêt de l’exécution d’un script qui retournera une erreur. Or, le serveur web interprètera cette erreur et transmettra au client des informations qui peuvent être intéressantes.

La structure des données résulte de la génération de contenu en fonction de la requête reçue. En général, la structure du contenu change peu pour une même ressource, ce qui permet de détecter une anomalie de l’application.

Par exemple, un résultat d’une injection SQL changera la structure de la donnée retournée, avec un surplus d’information. Un XSS injecté renverra un arbre HTML différent par rapport à un comportement normal.

Il est également possible de se baser sur le nombre de mots et de lignes retournées habituellement par un appel à une ressource.

Le volume des données diffère bien évidemment à chaque appel à une ressource dont le contenu est généré dynamiquement.

Cependant, cette fluctuation du volume reste dans des proportions raisonnables. Lors d’une attaque visant à récupérer un contenu supplémentaire, il est possible de détecter un changement important de volume de données retournées pour une même ressource appelée avec des paramètres identiques.

Par exemple, une injection SQL permettant de récupérer une base d’utilisateurs rajoutera un volume de donnée important dans la réponse.

Enfin, la présence de données sensibles est un marqueur intéressant. L’appel à une ressource retournant un numéro de carte de crédit pour un client d’une banque peut être considéré comme normal sur une application bancaire. L’appel à une ressource retournant une liste de numéros de cartes bancaires pour un utilisateur interne de la banque peut être acceptable sur une application bancaire.

Cependant, si l’on inverse les deux types d’utilisateurs, alors, il risque d’y avoir un problème. La présence de données sensibles liées à un type d’utilisateur permet de détecter un fonctionnement anormal de l’application. Par exemple, un utilisateur client d’une banque qui recevrait une liste de numéros de cartes bancaires constituerait très probablement une fuite d’informations.

Toutes ces données analysées et corrélées grâce aux différents mécanismes de sécurité contenus dans les composants i-Suite tels que le WAF, le WSSO ou la gateway XML  permettent de détecter des comportements anormaux sur les applications Web. Ces différents mécanismes associés à la logique métier de l’application à sécuriser, permettent de fournir une protection optimale des applications Web.

Matthieu Estrade

Popularity: 36%