Les ‘http referers’ non fiable pour faire de l’authentification

Tags:

Bon voici le récit de mes expériences avec les référents http au cours des dernières semaines. Premier conseil, si vous utilisez le référent pour identifier un individu, changez de techniques. Le passage de la balise ‘Méta referer’ dans les requêtes http ne sont tellement pas fiable que cela rend le processus inutile. Voici la problématique rencontrée : Mon Site ‘A’, en https, désire présenter un contenu exclusif http sur un site externe ‘B’. Auparavant, une application sur le site ‘A’ valide si l’usager a le droit ou non de percevoir le contenu de la page et réachemine le fureteur au site ‘B’. Voici quelques possibilités pour faire en sorte que cela fonctionne :

  1. Témoin (Cookie) Cela ne marche pas, puisque les deux sites n’ont pas le même nom de domaine. Le site B n’a pas accès au témoin du site A.
  2. Réponse http 301 redirect. Le site B vérifie que le référent est le site A Cela ne marche pas. Les fureteurs ne mettent jamais de référent lors de réacheminement.
  3.  Retour en Javascript window.location= »Site B ». Le site B vérifie que le référent est le site A Cela ne marche pas. La RFC indique que le référent ne doit pas être passé lors d’un passage d’un site https à un site http.
  4.  Changement du site A pour http au lieu de https. Retour en Javascript window.location= »Site B ». Le site B vérifie que le référent est le site A Ca fonctionne partiellement. Firefox n’a pas de problème et passe le référent. IE ne passe pas le référent lors de cette opération.
  5.  Changement du site A pour http au lieu de https. Retour en Javascript Identification du fureteur. Si Firefox => window.location= »Site B » si IE présentation d’une page avec un lien que l’on peut cliquer.. Le site B vérifie que le referer est le site A. Ca fonctionne correctement, mais occasionne des cliques de souris supplémentaire pour les utilisateurs d’IE. Autre considération, le référent est extrêmement facile à falsifier dans une requête http et que le contenu exclusif n’est pas vraiment protégé.

La solution correct est la suivante et elle est inspirée du travail fait par Paypal pour garantir une sécurité. L’application du site A vérifie la valide du compte. Si le compte est invalide, on présente une page d’abonnement. Si le compte est valide, on prépare un algorithme d’hachage sur l’usager ou un nombre pseudo aléatoire. On le garde en cache ou en base de données pour les prochaines minutes. On effectue un réacheminement 301 en incluant en paramètre le total mêlé ou le nombre. Le site B sur réception du URL lance une application. Cette application appel un service WEB sur le site A demandant si le total mêlé ou nombre en paramètre a été bien créer par lui. Si la réponse est positive, le contenu est présenté. Si la réponse est négative, on réachemine l’usager vers une page d’abonnement du site A. Simple, efficace et sécuritaire. Maintenant la question piège. Si le référent ne sert pas à identifier de manière sécuritaire l’internaute, a quoi sert-il ? Je vous fais un résumé de mes discussions avec Jean-Marc prochainement.

Articles récents