est-il sûr d'utiliser des variables de session - asp.net/c #
Donc, fondamentalement, je me demande si ma façon d’utiliser les variables de session est sûre.
J'ai un formulaire de connexion où l'utilisateur tape son nom d'utilisateur/mot de passe, il est paramétré puis interrogé, si le nom d'utilisateur/mot de passe existe, un ID utilisateur est renvoyé depuis la table db. Ceci est unique pour chaque utilisateur.
quand j’ai cette valeur, c’est là que je me demande si cette manière est un moyen sûr de stocker l’ID utilisateur dans la variable de session uID? de toute façon c'est comme ça que je le fais,
Session["uID"] = (int)dt.DefaultView[0]["userID"];
FormsAuthentication.RedirectFromLoginPage(username.Text, false);
Response.Redirect("userPage.aspx", false);
ensuite, la page est redirigée vers une autre page où j’utilise la variable de session pour récupérer les tables des utilisateurs de la base de données.
Merci d'avance pour vos commentaires
L'état de session est conservé entièrement côté serveur, quelle que soit la méthode de stockage utilisée (en mémoire, serveur d'état de session ou base de données).
Donc, à moins que votre serveur ne soit piraté, les variables de session sont sécurisées. Et au cas où votre serveur serait piraté, le pirate n'aurait accès aux données que dans sa propre session, à moins qu'il ne trouve le moyen d'analyser la mémoire du processus IIS.
Très sûres, les variables de session .NET ne sont pas identiques aux variables de cookies pouvant être visualisées du côté client. Les variables de session de cette instance ne sont accessibles qu'à partir du code C #.
Vous pouvez donc être sûr de savoir que la variable Session ne peut être modifiée par personne/chose autre que le code exécutant l'arrière-plan.
Pas tout à fait lié à votre question, mais pourrait être bon à savoir dans votre cas:
Vous pouvez également stocker un objet entier dans la session afin de pouvoir stocker un objet utilisateur dans la session, tel que
user_Class user = new user_Class();
user.UID = 1;
Session["User"] = user;
Ensuite, vous le rechargez au chargement de chaque page.
user_Class user = (user_Class)Session["User"];
Ensuite, vous pourriez obtenir user.UID de session à chaque fois.
En ce qui concerne les sessions, vous pouvez être assuré que les données ne sont pas directement accessibles. Si, pour une raison quelconque, votre application renvoie des données directement à partir de la session, celles-ci pourraient potentiellement être exploitées, mais comme il existe rarement une raison de le faire, le risque est donc assez minime.
La partie la plus risquée à propos des sessions se présente sous la forme d'un détournement de session. Vous voyez, même si toutes vos données sont stockées en toute sécurité sur le serveur, nous avons toujours le problème "HTTP sans état" à traiter. Il faut donc stocker une sorte d’identificateur sur le client pour que le serveur puisse rechercher les données de session appropriées. Mais si d’une manière ou d’une autre le système récupère cet ID, il peut se faire passer pour vous tant que le serveur garde la session active.
Hormis le fait de traiter en continu tout potentiel de création de scripts intersites sur votre site Web, vous ne pouvez vraiment rien faire à ce sujet sans une connexion sécurisée. Même dans ce cas, il peut être mal implémenté.
Tout va bien jusqu'à ce que votre site Web devienne trop grand pour un seul serveur. Ensuite, vous devez migrer votre fournisseur de session vers un serveur d’état ou le remplacer avec SQL Server qui finit par être un peu nul.
Voir http://msdn.Microsoft.com/en-us/library/ms178201%28v=vs.80%29.aspx pour une liste complète des problèmes liés à la sécurité des sessions.
Vous êtes toujours vulnérable même si YOU SERVEUR IS N'EST PAS COMPROMIS Session peut être facilement détourné en utilisant MITM Attack et lorsqu'un attaquant obtient votre session, il peut faire tout ce que vous pouvez faire. .
Vous pouvez utiliser des techniques pour éviter les détournements de session, mais souvenez-vous que vous êtes toujours vulnérable en cas de problème de codage, etc., ce qui rend votre application vulnérable.
Utilisation de SSL
SSL votre site
Générer Hash