Y a-t-il une raison (sécurité?) Pourquoi quelqu'un devrait renommer le nom de cookie asp.net session ou est-ce juste une option insensée d'ASP.NET?
6 Réponses :
1) il pourrait (légèrement) lent quelqu'un qui est (avec désinvolture) la chercher.
2) Vous voudrez peut-être cacher le fait que vous exécutez ASP.NET
2) Peut être vrai, mais le premier cadeau pour ASP.NET sera dans le marquage rendu et l'ID Mangling
Les cadeaux supplémentaires pour ASP.NET incluent la présence d'extensions de fichiers communes telles que .aspx, .asasmx, .axd; Les en-têtes de réponse de IIS comme X-Powered-by: ASP.NET. Plus subtilement, il y a le comportement de verrouillage de la session dans laquelle une demande d'utilisation de session doit remplir avant de commencer une autre.
Si plusieurs applications fonctionnant sous le même domaine sur le même serveur, vous pouvez bien vouloir avoir des noms de cookies de session séparés pour chacun, de sorte qu'ils ne partagent pas le même état de session ou pire encore écrasant mutuellement.
Voir aussi les notes pour le Formulaire authentifiant cookie Nom :
Spécifie le cookie HTTP à utiliser pour l'authentification. Si plusieurs applications sont exécutées sur un seul serveur et que chaque application nécessite un cookie unique, vous devez configurer le nom de cookie dans chaque fichier web.config pour chaque application.
Je ne suis pas un expert ASP.NET, mais ne définit pas le paramètre Cookie 'Path' en conséquence lors de l'utilisation de plusieurs applications sous le même domaine?
@Ferdinand Beyer - Cela pourrait faire, mais il n'y a pas d'attribut "chemin" ou même "domaine" sur la configuration de la session State - Notez que le chemin de cookie des formulaires indique "la valeur par défaut est une barre oblique (/), car la plupart Les navigateurs sont sensibles à la casse et n'enverront pas de cookies, s'il y a une inadéquation de cas de chemin. ». Vous vous ouvrez dans un monde potentiel de douleur.
Le nom de cookie d'authentification des formulaires n'est pas le même que le nom de la session Cookie (ce dernier est généralement appelé ASP.NET_SESSIONID et peut être modifié de manière indépendante des formulaires / nom de cookie de connexion)
@Davidroberts d'où mon commentaire "Voir aussi" - La documentation des formulaires Auth Cookie explique pourquoi vous pourriez vouloir le renommer, tandis que la session Cookie Doc n'a pas.
Mais je pense que cela est incroyablement trompeur d'avoir dans la réponse. L'explication et la justification ne sont pas nécessairement applicables car les formulaires Cookie et Session Cookie ne sont pas la même chose. Existe-t-il en fait des preuves (dans les docs) que collectant les noms de cookies de session provoquent l'effet décrit? Il fait pour les formes de cookie, évidemment - mais la session [State] Cookie?
Si vous exécutez des applications virtuelles sous votre site racine principal, il est possible que les cookies puissent se heurter, définir le chemin peut ne pas être peu fiable, car vous devez appliquer le comportement de la barre oblique et de la traînée, donc les avoir toutes définis sur le chemin de la racine, mais avec des noms différents. aidera vos applications à distinguer entre eux. Cela permettrait à chaque application de conserver leurs propres identifiants de session, sans avoir un impact sur d'autres applications visitées par le même utilisateur (session d'appel.Abandon en une élever le cookie, effacer la sessionID de toutes les autres applications, qui peuvent ne pas être souhaitées).
Je pense que c'est principalement une question de goût. Certaines personnes / entreprises souhaitent contrôler tous les aspects de leurs applications Web et pourraient simplement utiliser un autre nom pour la cohérence avec d'autres noms de cookies. Par exemple, si vous utilisez des noms de paramètres très courts de caractères sur tout au long de votre application, vous n'êtes peut-être pas comme des noms de session Cookie tels que AspessID.
Les raisons de sécurité peuvent s'appliquer mais Sécurité via obscurité est plutôt faible à mon avis.
ci-dessous Link fournit plus d'informations sur la raison pour laquelle les cookies de session doivent être renommés.
https://www.owasp.org/index.php/session_management_cheat_shetheet < / p>
"Le nom utilisé par l'ID de session ne doit pas être extrêmement descriptif ni offrir des détails inutiles sur le but et la signification de l'ID.
Les noms d'identification de la session utilisées par les cadres de développement de l'application Web les plus courants peuvent être facilement empreintes digitales [0], telles que PHPSESSID (PHP), JSessionID (J2EE), CFID & CFTOGN (COLDFUSION), ASP.NET_SESSIONID (ASP .NET ), etc. Par conséquent, le nom d'identification de la session peut divulguer les technologies et les langages de programmation utilisés par l'application Web.
Il est recommandé de modifier le nom d'identification de la session par défaut du cadre de développement Web vers un nom générique, tel que "ID". "
avec préfixes de cookie , vous pouvez ajouter un attribut de sécurité à votre cookie en nommant une manière particulière. Donc, dans ce cas, le renommage de votre cookie ASP.NET session a un impact sur la sécurité:
__ Secure- ... Les cookies ne peuvent être écrits qu'à partir de sites sécurisés (HTTPS).
-
__ host- ... Les cookies ne peuvent être écrits que du même domaine sécurisé. Donc, pas des sous-domaines ou des sites d'insécurité (HTTP).
Selon les spécifications suivantes, HTTPS: // Outils .ietf.org / html / brouillon-ietf-httpbis-cookie-préfixes-00 , que les navigateurs modernes implémentent, les préfixes sont utilisés pour rendre les choses plus sécurisées.
3.1. Le préfixe "__Secure-"
Si le nom d'un cookie commence par "__secure-", le cookie doit être:
- défini avec un attribut "sécurisé"
défini d'une URI dont le "schéma" est considéré "sécurisé" par l'utilisateur agent.
Le cookie suivant serait rejeté lorsqu'il est défini de n'importe quelle origine, comme Le drapeau "sécurisé" n'est pas défini
Cookie Ensemble: __Secure-SID = 12345; Domaine = exemple.com
tandis que ce qui suit serait accepté s'il est défini à partir d'une origine sécurisée
(E.G. " https://example.com/ ") et rejeté autrement:Cookie Ensemble: __Secure-SID = 12345; Sécurise; Domaine = exemple.com
3.2. Le préfixe "__Host-"
Si le nom d'un cookie commence par "__host-", le cookie doit être:
- défini avec un attribut "sécurisé"
- est à partir d'une URI dont le "schéma" est considéré comme "sécurisé" par l'utilisateur agent.
- Envoyé uniquement à l'hôte qui définit le cookie. C'est-à-dire un cookie nommé "__host-cookie1" défini à partir de " https://example.com " ne doit pas contenir un attribut «domaine» (et sera donc envoyé uniquement à "exemple.com", et pas à "sous-domaine.example.com.com").
envoyé à chaque demande d'hôte. C'est-à-dire un cookie nommé "__Host-cookie1" doit contenir un attribut "chemin" avec une valeur de "/".
Les cookies suivants seraient toujours rejetés:
Ensemble-Cookie: __host-sid = 12345 Ensemble-Cookie: __Host-SID = 12345; Ensemble sécurisé-Cookie: __host-sid = 12345; Domaine = example.com
Ensemble-Cookie: __host-sid = 12345; Domaine = exemple.com; Chemin = /
Ensemble-Cookie: __host-sid = 12345; Sécurise; Domaine = exemple.com; Chemin = /