Qu'est-ce qu'une attaque par redirection ouverte ?
Les applications Web redirigent souvent leurs utilisateurs sur une page de connexion à partir de laquelle ils peuvent accéder aux ressources via une authentification. En général, ce processus de redirection fait intervenir le paramètre returnUrl d'une chaîne de requête. Une fois l'utilisateur authentifié, il peut ainsi être redirigé vers l'URL demandée initialement.
Étant donné que cette URL est spécifiée dans une chaîne de requête, un pirate peut la falsifier. Une chaîne de requête falsifiée pourrait alors rediriger l'utilisateur vers un site externe et malveillant. C'est ce qu'on appelle une attaque par redirection ouverte.
Voici un exemple assez courant :
Un pirate veut accéder aux identifiants ou aux informations sensibles d'un utilisateur. Pour ce faire, il convainc ce dernier de cliquer sur un lien menant à la page de connexion et contenant une valeur returnUrl , comme :
http://www.mabanque.com/Compte/Login?returnUrl=/Accueil/Apropos.
L'utilisateur clique sur le lien malveillant :
http://www.mabanque.com/Compte/LogOn?returnUrl=http://www.mabanque1.com/Compte/Connexion.
L'utilisateur se connecte, puis est redirigé par le site légitime vers :
http://www.mabanque1.com/Compte/Login?returnUrl=https://www.mabanque.com/
Le site malveillant ressemble à s'y méprendre au site légitime. L'URL de retour redirige ensuite l'utilisateur vers le site d'origine.
Lorsque l'utilisateur voit une nouvelle fois s'afficher la page de connexion, il pense s'être trompé de mot de passe. Il saisit une nouvelle fois ses identifiants, que le site malveillant enregistre avant de le rediriger vers le vrai site. L'utilisateur n'a absolument pas remarqué la redirection.
Cela vous rappelle quelque chose ? Sans doute. C'est exactement le scénario que nous avons décrit au début du chapitre sur les attaques XSS. Les redirections ouvertes sont souvent utilisées en conjonction avec des attaques XSS ou XSRF/CSRF. Dans notre exemple, lors de l'attaque XSS, le pirate a injecté du code JavaScript dans un commentaire publié sur un blog. Ce code permettait de modifier le bouton de connexion de la page en lui ajoutant un paramètre returnURL. Il redirigeait ensuite l'utilisateur sur une page de connexion semblable à la page d'origine, mais hébergée sur le serveur du pirate qui va discrètement récupérer les identifiants.
Ces attaques sont difficiles à repérer pour les utilisateurs finaux, mais les développeurs peuvent assez facilement les bloquer.
Empêchez les attaques par redirection ouverte
En règle générale, partez du principe que toutes les données fournies par les utilisateurs ne sont pas fiables. Vous pourrez ainsi empêcher les attaques par redirection ouverte, mais aussi toutes les attaques évoquées dans ce cours. En effet, toutes ces attaques nécessitent l'injection d'un code malveillant ou des données via la saisie d'un utilisateur. Si votre application redirige ses utilisateurs en fonction du contenu d'une URL, assurez-vous que ces redirections se font au sein de votre application ou les dirigent vers une URL connue. En aucun cas, elles ne doivent avoir pour destination une URL fournie dans la chaîne de la requête.
LocalRedirect
Utilisez la méthode d'assistance LocalRedirect de la classe du contrôleur de base :
public IActionResult Action(string urlRedirection)
{
return LocalRedirect(urlRedirection);
}LocalRedirect lève une exception si une URL non locale est spécifiée. Sinon, elle se comporte comme la méthode Redirect .
IsLocalUrl
Utilisez la méthode IsLocalUrl pour tester les URL avant de procéder à la redirection :
private IActionResult RedirectionLocale(string urlRetour)
{
if (Url.IsLocalUrl(urlRetour))
{
return Redirect(urlRetour);
}
else
{
return RedirectToAction(nameof(HomeController.Index), "Home");
}
}La méthode IsLocalUrl protège les utilisateurs en leur évitant d'être redirigés par mégarde vers un site malveillant. Vous pouvez consigner les détails de l'URL fournie lorsqu'elle n'est pas locale alors que vous attendiez une URL locale. Cette mesure peut aider à détecter les attaques par redirection.
En résumé
Dans ce chapitre, nous avons vu les points suivants :
Lors d'une attaque par redirection ouverte, un pirate falsifie la chaîne d'une requête pour que l'utilisateur soit redirigé vers un site externe malveillant.
Ces attaques surviennent souvent en même temps qu'une attaque XSS ou XSRF, ou après une telle attaque.
Vous pouvez empêcher ces attaques en vous assurant que les redirections soient faites au sein de votre application ou vers une URL connue. En aucun cas, elles ne doivent avoir pour destination une URL fournie dans la chaîne de la requête.
Maintenant que nous avons vu les différentes façons par lesquelles un pirate peut injecter du code malveillant dans un site et comment les bloquer, parlons d'un type d'attaque encore plus dangereux, l'injection SQL.
