Vérifiez URL de redirection malveillante dans ASP.NET

Question

J'ai entendu parler de sites utilisant un autre site pour rediriger les utilisateurs vers leur propre site ou pour se cacher derrière un autre site. Dans mon code je redirige dans quelques endroits tels que poster un commentaire (il est plus facile d'utiliser une url de retour puis de trouver la page en utilisant les données fournies).

Comment puis-je vérifier si l'URL de retour est ma propre URL? Je pense que j'utilise des chemins absolus donc je peux facilement vérifier si le premier caractère est '/' mais alors je vais perdre la flexibilité relative. Cela m'interdit également de faire http://mysite.com/blah dans l'URL de redirection. Je pourrais patcher l'URL en ajoutant mysite + string mais je devrai déterminer si string est une URL relative ou déjà une URL mysite.com.

Quel est le moyen le plus simple de m'assurer que je ne redirige que vers mon site?

Answer 1

Que diriez-vous, si le redirectUrl contient ": //" (qui inclut http: //, https: //, ftp: //, etc.) alors il doit aussi commencer par "http://mysite.com". S'il ne contient pas ": //" alors c'est relatif et ne devrait pas poser de problème. Quelque chose comme ceci:

if (!(redirectUrl.Contains("://")^redirectUrl.IndexOf("http://mysite.com") == 0)) 
{ 
    Response.Redirect(redirectUrl); 
} 

Answer 2

Cela semble être une question étrange, et cela ne devrait pas être une préoccupation si vous avez un contrôle total sur le processus de redirection. Si pour une raison quelconque, vous autorisez l'entrée de l'utilisateur de participer activement à une redirection (comme dans le code ci-dessous)

Response.Redirect(someUserInput); 

Alors, oui, un utilisateur pourrait avoir votre code les envoyer à qui sait où. Mais si tout ce que vous faites est

Response.Redirect("/somepage.aspx") 

Ensuite, ces redirections seront toujours sur votre site.

Comme je l'ai dit, il semble que ce soit une question étrange. Les préoccupations les plus importantes en termes de saisie par l'utilisateur sont généralement les attaques par injection SQL et les scripts inter-sites. Je n'ai pas vraiment entendu parler de "redirections malveillantes".

Answer 3

Je n'avais pas pensé à cela auparavant, mais qu'en est-il de l'utilisation d'une version cryptée de l'URL dans le paramètre de chaîne de requête? Vous pouvez également conserver une liste des URL réelles dans un magasin persistant (persistant pendant quelques heures, peut-être), et dans la chaîne de requête, il suffit d'inclure l'index dans le stockage persistant des URL. Puisque vous seriez le seul code à manipuler ce magasin côté serveur persistant, le pire qu'un utilisateur malveillant pourrait faire serait de rediriger vers une autre URL valide.