2010-10-28 9 views
7

Je tente de sécuriser un site Web que je développe actuellement à l'aide de ASP.NET MVC 2.0 et de l'authentification par formulaire. Afin de sécuriser le cookie d'authentification par formulaire, je veux définir la propriété requiresSSL sur true afin que le cookie ne soit envoyé par les navigateurs que lorsque la connexion est sous SSL et que toutes les ressources nécessitant une autorisation soient sous SSL. Mon problème est que nous utilisons le routage de demande d'application pour remplir un certain nombre de fonctions, l'une étant le déchargement SSL, donc au moment où une requête touche un serveur web de notre ferme, la requête n'est plus sous SSL et FormsAuthentication. La méthode SetAuthCookie échoue car une connexion SSL est requise pour définir le cookie lorsque requiresSSL est spécifié.Sécurisation du cookie d'authentification des formulaires lors du déchargement SSL

N'importe qui a des idées pour travailler ici!

Merci

+0

+1, je serais également intéressé par les solutions à ce problème. –

Répondre

3

donc j'ai un travail autour de cela, si quelqu'un a une meilleure idée s'il vous plaît ne hésitez pas à commenter. Essentiellement, vous devez intercepter la réponse à la fin de la requête et définir manuellement la propriété Secure sur le cookie d'authentification des formulaires, ce qui est assez évident, vous devrez également définir la propriété requireSSL dans la configuration d'authentification des formulaires sur false. Gardez également à l'esprit que nous ne voulons pas activer HTTPS pour l'ensemble du site pour les utilisateurs authentifiés, d'où ce travail.

Il y a quelques mises en garde à cette approche et quelques éléments à connaître.

  1. J'ai trouvé au cours des essais que le cookie d'authentification a toujours été écrit dans la réponse, donc je continuais d'écraser le cookie d'authentification valide dans le navigateur avec un cookie d'authentification vide, pour contourner ce que j'ai inclus une certaine logique dans le module HTTP pour contourner ce problème, voir l'extrait de code ci-dessous.

  2. Toutes les demandes à l'application nécessitant une autorisation doivent être sous SSL, sinon la demande ne contiendra pas le cookie d'authentification afin d'authentifier l'utilisateur. Parce que vous ne passez que le cookie d'authentification pour les demandes SSL, vous aurez besoin d'un autre mécanisme pour indiquer à votre application que l'utilisateur actuel est authentifié quand il navigue dans les zones non SSL du site, j'ai implémenté ceci avec un cookie supplémentaire qui est défini lorsque l'utilisateur se connecte et n'a pas de date d'expiration définie, expirera donc à la fin de la session des utilisateurs, bien sûr ce cookie est supprimé si l'utilisateur se déconnecte.

est inférieure à la logique mise en oeuvre dans un module HTTP pour affecter ce qui précède, j'ai testé ce dernier quelques heures et n'ont pas rencontré de problèmes encore, je ne manquerai pas de mettre à jour ce poste si je faire!


Nous ne devrions jamais envoyer un cookie d'authentification au client si l'utilisateur vient connecté est ici la logique

  1. Si la demande a un cookie d'authentification de l'utilisateur est déjà authentifié et sous SSL Assurez-vous donc de ne pas envoyer un nouveau cookie d'authentification dans la réponse .
  2. Si la requête ne possède pas de cookie d'authentification mais qu'un cookie d'authentification est valide dans la réponse, définissez le cookie d'authentification de réponse à sécuriser, afin qu'il soit uniquement transmis par le navigateur sous SSL.
  3. Si la demande n'a pas de cookie d'authentification et que la réponse contient un cookie d'authentification invalide ou vide, assurez-vous de supprimer le cookie de réponse pour ne pas remplacer le cookie valide dans le navigateur client.
private void EndRequest(object sender, EventArgs e) 
{ 
    var application = (HttpApplication)sender; 

    if (ValidRequest(application.Request) && application.Response.Cookies.Count > 0) 
    { 

     //only do the below if the user is not logging out the site, if the user is logging out we can 
     //leave the default forms authentication behaviour which is to expire the auth cookie 
     if (application.Request.AppRelativeCurrentExecutionFilePath != "~/authentication/logoff") 
     { 
      var requestAuthCookie = application.Request.Cookies[FormsAuthentication.FormsCookieName]; 
      var responseAuthCookie = application.Response.Cookies[FormsAuthentication.FormsCookieName]; 

      if (requestAuthCookie != null && responseAuthCookie != null && responseAuthCookie.Value.IsNullOrEmpty()) 
      { 
       application.Response.Cookies.Remove(FormsAuthentication.FormsCookieName); 
      } 
      else if (responseAuthCookie != null && !responseAuthCookie.Value.IsNullOrEmpty()) 
      { 
       responseAuthCookie.Secure = true; 
       application.Response.Cookies.Remove(FormsAuthentication.FormsCookieName); 
       application.Response.Cookies.Add(responseAuthCookie); 
      } 
      else if (responseAuthCookie == null || responseAuthCookie.Value.IsNullOrEmpty()) 
      { 
       application.Response.Cookies.Remove(FormsAuthentication.FormsCookieName); 
      } 
     } 
    } 
} 
2

SSL Offload devrait vous permettre d'établir une connexion SSL à partir du transcodeur SSL sur le serveur Web.

La connexion SSL du déchargeur SSL au serveur Web doit utiliser le cryptage le plus léger et le plus rapide (et probablement le plus faible) disponible.

Ceci vous permet d'utiliser des cookies sécurisés, de réduire la charge de chiffrement sur les serveurs et d'éviter la modification de votre code.

+0

Bonne idée, mais cela introduit une couche supplémentaire de déconner avec des certificats entre les offloaders et les serveurs. Il serait intéressant de trouver une solution sans – Anthony

+0

Je suis d'accord avec vous. Cela dit ... La solution la plus courante que j'ai vu est d'établir une connexion entre le déchargeur SSL et le serveur sans authentification client (déchargeur SSL). Si cette connexion passe par un réseau de confiance, il pourrait même aller en clair. Si vous devez fournir les informations de certificat client à l'application, les informations de certificat peuvent être placées dans un en-tête HTTP (cela nécessite une modification de l'application) –

Questions connexes