Dans la semaine du 23 août 2022, un mystérieux avis de passage de La Poste a été déposé dans votre boîte aux lettres… Tout semble authentique et, que vous attendiez un colis ou non, il est normal d’aller regarder de quoi il s’agit. Vous scannez le QR code ou accédez à l'URL pour (re)planifier la livraison, entrez quelques informations personnelles sur un formulaire aux couleurs de La Poste et paf, voilà vos données volées par un hacker peu scrupuleux qui aura exploité une vulnérabilité de type Open Redirect du site de La Poste !

Vous l’aurez compris, il s’agissait bien d’un faux avis de passage. Mais comment est-ce qu’on en arrive là à partir d’une URL ?

💡 La structure d’une URL

Pour commencer, il est nécessaire de comprendre la structure et le fonctionnement d’une URL. Utilisons l’exemple ci-dessous :

Dans l’ordre nous avons :

• Le protocole (https), le sous-domaine (www), le nom de domaine (domain), le TLD (Top Level Domain) (com) et le path (page)
• Les paramètres d’URL : key1=value1&key2=value2

Ici on va principalement s’intéresser aux paramètres d’URL : ceux-ci sont séparés du reste de l’URL par le préfixe "?" , puis entre eux par "&". Les développeurs les utilisent pour extraire certaines valeurs depuis l’URL.

Exemple : www.domain.com/page?index=2 pour indiquer qu’on veut être sur la page numéro 2

Une URL ne peut comporter que des caractères alphanumériques, quelques caractères spéciaux (-, ., _, ~) et d’autres ayant une signification particulière comme on vient de le voir (?, /, #). Les autres caractères doivent, eux, être encodés.

Exemple :

www.domain.com/il y a des espaces => www.domain.com/il%20y%20a%20des%20espaces (un espace étant encodé par %20)

Les navigateurs sont ensuite capables de décoder ces URL dans le sens inverse. Plus globalement, il est possible d’encoder n’importe quel caractère, même les caractères qui ne nécessitent pas d’encodage. A quoi bon ? Lisez la suite !

🕵️ Explication de la faille du site de La Poste

Le fonctionnement des vulnérabilités Open Redirect s’appuie essentiellement sur deux principes :

• Un abus de confiance de la part de l’utilisateur car elles exploitent les fonctionnalités de redirection déjà présentes sur des sites légitimes
• Un encodage du lien de redirection pour rendre l'attaque plus difficilement détectable par un oeil humain

Par exemple, supposons que www.google.com propose une fonctionnalité de redirection qu’on peut utiliser en indiquant un lien via le paramètre d’URL redirect. Le déroulement de l’attaque serait le suivant :

1. Un utilisateur accède à un lien qu’un attaquant lui aura transmis d’une manière ou d’une autre, mais en lequel il a confiance car il s’agit d’un site légitime et/ou reconnu : www.google.com?r%65direct=%77%77%77%2eh%61cker%2ecom. Il est important de comprendre qu’une fois qu’il clique dessus, l’utilisateur ne “voit” pas les étapes suivantes et se retrouve directement à l’étape 5.

2. Son navigateur décode automatiquement l’URL pour envoyer la requête : www.google.com?redirect=www.hacker.com

3. Le serveur qui reçoit la requête interprète l’URL et notamment ses paramètres d’URL. Comme un lien est indiqué dans un paramètre redirect, il répond à la requête en indiquant la redirection à effectuer par le navigateur de l’utilisateur vers la valeur du paramètre en question : www.google.com?redirect=www.hacker.com

4. Le navigateur de l’utilisateur reçoit la réponse du serveur et effectue une redirection vers l’URL spécifiée, c’est-à-dire vers le site de l’attaquant : www.hacker.com

5. La victime est sur le site de l’attaquant.

Une fois l’utilisateur sur le site de l’attaquant, plusieurs types d’attaques sont possibles dans des buts divers et variés, comme le vol d’identifiants et de données via un faux formulaire incitant la victime à rentrer ses informations personnelles.

Vous avez tout compris ? Reprenons donc l’attaque de La Poste !

1. Grâce au faux avis de passage, l’attaquant incite la victime à accéder au site de La Poste : www.laposte.fr/sw%69tch-site?sw%69tchSiteRe%71uestUR%49=%2F/cutt%2Ely/XZHR7pb
   
2. Le navigateur de la victime décode l’URL et contacte le serveur : www.laposte.fr/switch-site?switchSiteRequestURI=//cutt.ly/XZHR7pb
   
   
3. Le serveur reçoit la requête et récupère un lien de redirection dans le paramètre d’URL switchSiteRequestURI.
   
4. Il renvoie ensuite sa valeur au navigateur de la victime pour qu’il se redirige automatiquement dessus : www.laposte.fr/switch-site?switchSiteRequestURI=//cutt.ly/XZHR7pb
   
5. Le navigateur de l’utilisateur effectue une redirection vers le lien renvoyé par le serveur : //cutt.ly/XZHR7pb
   
6. La victime est sur le site pirate qui reproduit un faux formulaire de La Poste.

🛡 Comment se protéger ?

En tant que développeur

• Tout simplement en ne développant aucune fonctionnalité de redirection 🤡
• Si cela n’est pas possible, il faut a minima ne pas rendre le lien de redirection modifiable via un input utilisateur
• Si cela n’est toujours pas possible, restreindre les redirections possibles à une allow list ou (encore mieux) à un domaine
• On peut également songer à prévenir l’utilisateur de la redirection pour le rendre plus alerte

En tant qu’utilisateur

• L’éternelle recommandation : vérifier l’URL lorsqu'on vous demande des informations sensibles
• Porter une attention particulière aux paramètres ayant l’air d’indiquer une redirection (ex : redirect, switch, target, url, …)

Nous avons pour ambition de sécuriser le web, et pour atteindre cet objectif, nous avons besoin de vous ! Si vous avez des questions, des suggestions ou le moindre doute, n'hésitez pas à contacter notre équipe sécurité : security@theodo.fr.