Attaques man-in-the-middle

mieux protéger une application internet

Ce site ne sera plus alimenté de contenu après août 2014. Tous les nouveaux articles seront redigés pour www.waitingforcode.com
Quand on entend man-in-the-middle (MITM), on pense souvent à une affaire de tromperie. Mais dans le web cette expression prend toute autre signification. Dans ce contexte de sécurité des applications internet, on est amenés à penser à une intrusion dans la communication entre le client (internaute) et le serveur (site internet).

A travers cet article vous allez voir de quoi il s'agit. Dans cette première partie on parlera des attaques possibles. Ensuite on verra des méthodes de protection qui peuvent rendre l'attaque plus difficile.

Plusieurs couettes de l'homme du milieu
Notre serial lover peut agir dans les milieux différents. Il peut détériorer le train de vie d'une connexion SSL ainsi que celui d'un protocole
de résolution d'adresse (ARP). On distingue ainsi
4 types d'attaque : DNS cache poisoning, SSL hijacking, session hijacking et ARP cache poisoning.

DNS cache poisoning
Chaque nom de domaine pointe vers une adresse IP du serveur. Ce serveur renvoie la réponse sous format d'une page web. En même temps, afin d'accélérer la lecture, le serveur DNS garde la correspondance entre le nom de domaine et l'adresse IP de la machine en cache. Et c'est à ce stade-là qu'une personne malveillante peut effectuer son attaque.

L'attaque se base sur l'émission des informations fausses par le serveur de l'attaquant. Cependant, ces informations doivent correspondre à ce qui est attendu par le serveur cible. Si c'est le cas, le serveur cible accepte le paquet et le met dans son cache. Si dans les informations envoyées se trouve une
nouvelle adresse IP, c'est désormais lui qui sera liée au nom de domaine.

SSL hijacking
La communication dans le protocole SSL (Secure Socket Layers) consiste en utilisation des certificats délivrés par un tiers dans le but de valider la conformité du serveur. En gros, le client envoie une demande. Le serveur lui renvoie un certificat signé par une autorité de certification (CA). Ensuite l'internaute vérifie auprès des tiers (toujours autorités de certification) si le certificat renvoyé est valable. Si c'est le cas, le client crée une clé aléatoire, chiffrée avec la clé publique du serveur. Le serveur reçoit le paquet. Il déchiffre la clé de session avec sa clé privée et identifie l'internaute. Grâce à ce protocole, les deux acteurs possèdent une clé commune dont ils sont seuls connaisseurs.


Cependant Moxie Marlinspike, chercheur en sécurité informatique, a découvert une faille potentielle. Une faille qui ne réside pas dans le protocole lui-même mais plutôt dans le "pont" entre la communication non cryptée et cryptée. Or, souvent la connexion cryptée est appelée depuis une connexion non cryptée via un lien ou la réponse renvoyée par le serveur contenant l'en-tête 302. C'est à ce moment-là que l'attaquant s'incruste dans le trafic.


session hijacking
On a déjà abordé le sujet. Vous pouvez consulter l'explication de session hijacking sur le blog. Juste pour un court rappel, l'attaque consiste à voler l’identité de l'internaute grâce à la possession de l'identifiant de sa session. On peut prendre contrôle sur sa session grâce à l'écoute du trafic, comme le fait man-in-the-middle.


Une fois le paquet intercepté, on peut l'utiliser pour accéder à la ressource demandée par le client. On peut ainsi exploiter ses cookies afin de consulter sa boîte e-mail ou son compte sur un réseau social.


ARP cache poisoning
Le protocole ARP est utilisé dans les réseaux LAN et WiFi. Il a pour but de faciliter la "conversation" entre les adresses IP et MAC des machines constituant le réseau.

Connu aussi en tant qu'ARP spoofing, l'une de ses finalités ressemble à celle de DNS poisoning. En écoutant le trafic dans son réseau, l'attaquant peut intercepter les messages envoyés entre les ordinateurs et truquer la réponse. Par exemple, il peut rediriger les requêtes vers des adresses usurpées. Il peut donc prétendre d'être la copie conforme de PayPal ou de Facebook et attendre de recevoir les données de connexion qu'il pourra exploiter par la suite.

L'attaquant peut également, à condition qu'il n'aime pas ses voisins, de bloquer tout le trafic dans le réseau.

Comment se protéger contre man-in-the-middle ?
Les points importants sont la sécurisation des machines le monitoring et l'analyse du trafic. Ensuite, en fonction de l'attaque, on peut utiliser des renforts différents. Par exemple, pour DNS poisoning, on peut employer DNSSEC, un signature digitale des données. Grâce à cela il s'assure de la validité de réponse en protégeant les données en intégralité.

Dans le cas de SSL hijacking, on parle souvent de la méthode d'attaque nommée HTTPS stripping. Elle consiste à changer tous les liens HTTPS en HTTP. Dans cette situation il faut se fier à la vigilance de l'internaute. La page sécurisée est assez caractéristique dans le navigateur car elle contient soit un cadenas, soit une barre à la couleur du certificat (bleu, vert, en savoir plus). Donc il est presque impossible de voir que le contenu retourné n'est pas sécurisé.

Vous pouvez aussi consulter les protections contre session hijacking. Elles ne seront pas développées dans cet article.

Les attaques de l'homme du milieu sont en très grande partie liées au réseau. Or, qu'est-ce que c'est l'internet ?

Pour en savoir plus :
- simulation de l'attaque
- la preuve qu'il faut protéger la connexion entre le serveur et la base de données
- la problématique de la protection SSL
- l'instruction de l'installation du SSL sur Apache2 : partie 1,
partie 2,
partie 3
- la série de Chris Sanders sur les attaques MITM : partie 1,
partie 2,
partie 3,
partie 4.

L'article écrit en rythme de:
Goldee - Un rêve, une idée
Bartosz KONIECZNY 08-08-2011 12:09 sécurité des applications web
Un conseil Symfony2

Comment valider les checkboxes avec Symfony2 ?

La validation des checkboxes sous Symfony2 se déroule avec une contrainte appelée ChoiceConstraint.

Voici l'exemple de l'utilisation:

$metadata->addPropertyConstraint('orderPreferedGift', new Choice(array('choices' => Gifts::getGiftTypes(true), 'multiple' => true, 'min' => 1,  'multipleMessage' => "Veuillez choisir au moins un type de cadeau", 'groups' => array('validationGroup'))));


Cette contrainte est très puissante. On peut déterminer par exemple la quantité des champs minimale ou maximale à cocher par utilisateur. Il est également possible de vérifier le types des valeurs.