Firesheep a mis au premier plan la question des échanges de cookies non sécurisés.
Comment pouvez-vous vous assurer que tous les échanges de cookies sont forcés de se produire uniquement via une connexion sécurisée SSL au serveur lorsque vous communiquez avec un utilisateur Web?
Notre scénario est que l'application Web est écrite en ASP.NET 4.0 et hébergée sur Windows Server 2008 R2 exécutant IIS 7.5 si cela rétrécit la portée de certains.
Vous pouvez utiliser app.config pour le forcer; le format est (dans le <system.web>
section)
<httpCookies domain="String"
httpOnlyCookies="true|false"
requireSSL="true|false" />
donc vous voulez vraiment, au minimum
<httpCookies requireSSL='true'/>
Mais de préférence, vous activerez également httpOnlyCookies, à moins que vous ne fassiez du javascript vraiment accrocheur.
Le moyen le plus sûr de protéger votre site contre Firesheep (et les attaques associées):
Déplacer vers la protection SSL à l'échelle du site : déplacez l'ensemble de votre site vers HTTPS et désactivez tous les accès HTTP. En d'autres termes, protégez l'intégralité de votre site avec SSL. Voici quelques ressources supplémentaires pour le faire: comment se protéger contre Firesheep , avantages et inconvénients de SSL à l'échelle du site , pourquoi SSL protège contre Firesheep .
Définissez l'indicateur SECURE sur tous les cookies : chaque fois que le serveur définit un cookie, organisez-le pour définir l'indicateur SECURE sur le cookie. L'indicateur SECURE indique au navigateur de l'utilisateur de ne renvoyer ce cookie que via des connexions sécurisées SSL (HTTPS); le navigateur n'enverra jamais de cookie SÉCURISÉ sur une connexion non chiffrée (HTTP). L'étape la plus simple consiste à définir ce drapeau sur chaque cookie utilisé par votre site.
Aussi, je recommande quelques étapes supplémentaires:
<SCRIPT SRC=...>
), Je vous recommande de vous assurer qu'ils font référence aux URL HTTPS; sinon, vous exposez la sécurité de votre site à des attaques actives. (Voir aussi Jeremiah Grossman's FAQ sur les widgets tiers .) Pour éviter d'inonder vos utilisateurs avec avertissements à contenu mixte , vous vous voulez vous assurer que tout le contenu, y compris les images et bibliothèques tierces, est également livré via HTTPS.Certains pourraient soutenir que ce qui précède est exagéré. Dans certains cas, il peut être possible de se protéger contre Firesheep en utilisant SSL sur une partie seulement du site. Cependant, cela nécessite des soins et des connaissances détaillées, et il est plus difficile de bien faire les choses. Étant donné que vous devez poser la question ici, je vous recommande personnellement de commencer avec SSL à l'échelle du site; vous avez de meilleures chances de bien faire les choses.
Comment implémenter cela dans IIS : Je ne suis pas un expert IIS, donc je ne peux pas vous donner une recette définitive sur comment implémenter ces étapes dans IIS. Cependant, cette référence sur activation de SSL sur IIS peut vous être utile. Il semble que vous puissiez cliquer avec le bouton droit sur la racine du site, choisir Properties
, cliquez sur l'onglet Directory Security
, puis dans Secure Communications
, cliquez sur Edit
et activez Require Secure Channel (SSL)
. Je ne sais pas comment configurer IIS pour définir automatiquement l'indicateur SECURE sur tous les cookies. Pour migrer un site existant, je vous recommande de configurer une redirection afin que toute personne visitant une page HTTP soit redirigée vers HTTPS. Les références suivantes peuvent vous aider ( non testé): redirection vers HTTPS , trois méthodes de redirection vers HTTPS . Si vous migrez un site existant, vous devrez également modifier tous les liens et références vers votre site à partir de http:
URL vers https:
URL. Je ne sais pas comment configurer ASP.NET pour définir l'indicateur SECURE sur tous les cookies, mais je pense que vous pouvez ajouter cookieRequireSSL="true"
Ou <httpCookies requireSSL="true">
Sur votre Web.config
; cela est important à faire, et particulièrement important si vous avez activé HTTP ou si vous avez une sorte de redirection des pages HTTP vers les pages HTTPS. Enfin, il y a beaucoup de matériel publié sur optimisation des performances pour HTTPS .
Je suis tombé sur ce fil tout en résolvant de me délivrer. La résolution que j'ai eue est que les chemins des cookies sont sensibles à la casse. Voici la question connexe.
https://stackoverflow.com/questions/399982/why-are-cookie-paths-case-sensitive
Ma résolution était de rediriger la page de destination vers le bon chemin. Assurez-vous de rechercher les boucles de redirection possibles.
url.com/VirtualDirectory/default.aspx ->
// qui donnera maintenant le chemin correct url.com/virtualdirectory/default.aspx response.redirect ("~/default.aspx");