Sécurité & session
ephp
-
khida Messages postés 25 Statut Membre -
khida Messages postés 25 Statut Membre -
salut,
j'utilise souvent les sessions pour gérer l'accés à des membres . seulement je veut savoir si il ya un risque au niveau de la sécurité en utilisant les sessions. si oui quels sont les solutions pour remédier à ce probleme.
merci à vos réponses!
j'utilise souvent les sessions pour gérer l'accés à des membres . seulement je veut savoir si il ya un risque au niveau de la sécurité en utilisant les sessions. si oui quels sont les solutions pour remédier à ce probleme.
merci à vos réponses!
A voir également:
- Sécurité & session
- Question de sécurité - Guide
- Votre appareil ne dispose pas des correctifs de qualité et de sécurité importants - Guide
- Mode securite - Guide
- Clé de sécurité windows 10 gratuit - Guide
- Www.yahoomail.com ouverture de session ✓ - Forum Yahoo mail
10 réponses
Je suppose que l'identifiant de session est stocké dans un cookie ?
Le risque principal de ce genre de chose c'est le vol du cookie:
- par exemple si l'utilisateur ne se délogue pas.
- si l'utilisateur se fait voler son cookie en cours de session (sniffer). Ou pire: se faire voler le mot de passe sur la page de login (puisque le mot de passe est transmis en clair par le navigateur).
Pour le premier cas, il suffit d'utiliser uniquement des cookies de session: ils ne sont pas écrits sur disque et disparaissent quand le navigateur est fermé.
Par contre, il faut bien veiller à toujours proposer à l'utilisateur un lien qui permet de fermer sa session, pour le cas où il ne pourrait pas fermer le navigateur (exemple: cybercafés, bornes...)
Pour le second, il suffit de passer en SSL (HTTPS).
HTTPS chiffrant les échanges entre le client et le serveur, il est impossible de sniffer les informations échangées, y compris le cookie.
Le risque principal de ce genre de chose c'est le vol du cookie:
- par exemple si l'utilisateur ne se délogue pas.
- si l'utilisateur se fait voler son cookie en cours de session (sniffer). Ou pire: se faire voler le mot de passe sur la page de login (puisque le mot de passe est transmis en clair par le navigateur).
Pour le premier cas, il suffit d'utiliser uniquement des cookies de session: ils ne sont pas écrits sur disque et disparaissent quand le navigateur est fermé.
Par contre, il faut bien veiller à toujours proposer à l'utilisateur un lien qui permet de fermer sa session, pour le cas où il ne pourrait pas fermer le navigateur (exemple: cybercafés, bornes...)
Pour le second, il suffit de passer en SSL (HTTPS).
HTTPS chiffrant les échanges entre le client et le serveur, il est impossible de sniffer les informations échangées, y compris le cookie.
merci pour votre réponse juste une autre question si il ya des docs concernant SSL ou autre outil de cryptage de données
Pour SSL, vois la documentation fournie avec le serveur web.
(L'activation de SSL est différente pour chaque serveur web.)
(L'activation de SSL est différente pour chaque serveur web.)
Salut,
Ce sujet m'interresse énormément mais je ne comprend pas bien l'histoir de vos cookie (en faite je ne me suis jamais interressé au cookie).
Mais voila, j'utilise une base de données pour enregistrer les utilisateur avec leur login et mot de passe. Je me demande alors si pour la sécuriter je doit tout de même utiliser le SSL (que je ne connait absolument pas).
En faite, ce qui m'arrangerai le plus soit que l'utilisateur n'est qu'a se délogué pour qu'il n'y ai pas de problème.
Ce sujet m'interresse énormément mais je ne comprend pas bien l'histoir de vos cookie (en faite je ne me suis jamais interressé au cookie).
Mais voila, j'utilise une base de données pour enregistrer les utilisateur avec leur login et mot de passe. Je me demande alors si pour la sécuriter je doit tout de même utiliser le SSL (que je ne connait absolument pas).
En faite, ce qui m'arrangerai le plus soit que l'utilisateur n'est qu'a se délogué pour qu'il n'y ai pas de problème.
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Le cookie sert à mémoriser l'identifiant de session de l'utilisateur.
Quand l'utilisateur se connecte (login/mot de passe), le système lui attribue un numéro de session au hasard qui est stocké dans un cookie.
Se déloguer = détruire le cookie de l'utilisateur et terminer la session sur le serveur.
Sans SSL, il y a la possibilité (peu probable, mais elle existe) que quelqu'un puisse "sniffer" les paquets de données échangés.
C'est à dire, voir absolument tout ce qui a été transmis entre le l'utilisateur et le serveur (login, mot de passe, données échangées...).
HTTPS permet de se protéger de cela.
(C'est pour cette raison que tous les sites des banques où il faut entrer des informations confidentielles sont en HTTPS.)
Quand l'utilisateur se connecte (login/mot de passe), le système lui attribue un numéro de session au hasard qui est stocké dans un cookie.
Se déloguer = détruire le cookie de l'utilisateur et terminer la session sur le serveur.
Sans SSL, il y a la possibilité (peu probable, mais elle existe) que quelqu'un puisse "sniffer" les paquets de données échangés.
C'est à dire, voir absolument tout ce qui a été transmis entre le l'utilisateur et le serveur (login, mot de passe, données échangées...).
HTTPS permet de se protéger de cela.
(C'est pour cette raison que tous les sites des banques où il faut entrer des informations confidentielles sont en HTTPS.)
OK.
Mes il y a moyen d'utiliser les session sans utiliser de cookie. Donc dans ce cas il n'y à pas de transmission entre le serveur et l'utilisateur.
A moins que les sessions fonctionne comme un cookie et écrive des chose sur disque dure de l'utilisateur.
Non?
Mes il y a moyen d'utiliser les session sans utiliser de cookie. Donc dans ce cas il n'y à pas de transmission entre le serveur et l'utilisateur.
A moins que les sessions fonctionne comme un cookie et écrive des chose sur disque dure de l'utilisateur.
Non?
A un moment où un autre, quand le serveur web voit arriver une requête HTTP, il faut qu'il sache de quel utilisateur ça vient.
Donc il faut bien, que l'utilisateur s'identifie en envoyant quelquechose au serveur, quelquechose qu'il a stocké chez lui (un identifiant, un identifiant et un mot de passe, ou autre chose.)
Envoye le mot de passe à chaque requête est possible, mais ce n'est pas très sûr.
Le système des sessions permet d'améliorer un peu la sécurité.
C'est le serveur qui envoie au client son numéro de session.
Le client doit le renvoyer au serveur avec chaque requête HTTP.
Le plus souvent, on stock l'identifiant de session dans un cookie, mais on est pas obligé:
On peut par exemple le stocker dans l'URL, mais bon, c'est pas terrible.
Le cookie reste la meilleure solution.
Avec un serveur HTTP, dans tous les cas, il faut que le client stock sa session.
(Car HTTP n'est pas un protocole en mode connecté.)
Donc il faut bien, que l'utilisateur s'identifie en envoyant quelquechose au serveur, quelquechose qu'il a stocké chez lui (un identifiant, un identifiant et un mot de passe, ou autre chose.)
Envoye le mot de passe à chaque requête est possible, mais ce n'est pas très sûr.
Le système des sessions permet d'améliorer un peu la sécurité.
C'est le serveur qui envoie au client son numéro de session.
Le client doit le renvoyer au serveur avec chaque requête HTTP.
Le plus souvent, on stock l'identifiant de session dans un cookie, mais on est pas obligé:
On peut par exemple le stocker dans l'URL, mais bon, c'est pas terrible.
Le cookie reste la meilleure solution.
Avec un serveur HTTP, dans tous les cas, il faut que le client stock sa session.
(Car HTTP n'est pas un protocole en mode connecté.)
oui en utilisant les sessions il ya transmission entre le serveur et le client c'est pour cela que je pose cette question si il y a des docs qui nous permet d'assurer plus de sécurité à nos sites . et merci
Donc dans tout les cas, même si on utilise les session sans cookie, il faut utiliser le SSL si on veut sécuriser le données?
