Sécurité & session
Fermé
ephp
-
16 avril 2004 à 13:09
khida Messages postés 24 Date d'inscription mardi 30 mai 2006 Statut Membre Dernière intervention 6 juillet 2009 - 18 juin 2007 à 16:26
khida Messages postés 24 Date d'inscription mardi 30 mai 2006 Statut Membre Dernière intervention 6 juillet 2009 - 18 juin 2007 à 16:26
A voir également:
- Sécurité & session
- Mode securite - Guide
- Session invalide ou obsolète - Forum Consommation & Internet
- Session expirée facebook piratage ✓ - Forum Facebook
- Désactiver sécurité windows - Guide
- Ants session déconnectée - Forum Services en ligne
10 réponses
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 657
16 avril 2004 à 13:28
16 avril 2004 à 13:28
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
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 657
16 avril 2004 à 13:54
16 avril 2004 à 13:54
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.)
Mr.White
Messages postés
251
Date d'inscription
jeudi 24 avril 2003
Statut
Membre
Dernière intervention
17 juillet 2012
53
16 avril 2004 à 14:05
16 avril 2004 à 14:05
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
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 657
16 avril 2004 à 14:39
16 avril 2004 à 14:39
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.)
Mr.White
Messages postés
251
Date d'inscription
jeudi 24 avril 2003
Statut
Membre
Dernière intervention
17 juillet 2012
53
16 avril 2004 à 14:55
16 avril 2004 à 14:55
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?
sebsauvage
Messages postés
32893
Date d'inscription
mercredi 29 août 2001
Statut
Modérateur
Dernière intervention
21 octobre 2019
15 657
16 avril 2004 à 15:13
16 avril 2004 à 15:13
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
Mr.White
Messages postés
251
Date d'inscription
jeudi 24 avril 2003
Statut
Membre
Dernière intervention
17 juillet 2012
53
20 avril 2004 à 12:46
20 avril 2004 à 12:46
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?
khida
Messages postés
24
Date d'inscription
mardi 30 mai 2006
Statut
Membre
Dernière intervention
6 juillet 2009
18 sept. 2006 à 15:37
18 sept. 2006 à 15:37
Bonjour
SVP puisque vous etes ds le domaine est ce que vous pouvez m'nvoyer la procdure qui permet de saisir le nom de session de l'utilasateur ds ma table (pour voir qui a maj le dossier sachant que j'ai choisi l'authentification windows et ASP.net
merci
SVP puisque vous etes ds le domaine est ce que vous pouvez m'nvoyer la procdure qui permet de saisir le nom de session de l'utilasateur ds ma table (pour voir qui a maj le dossier sachant que j'ai choisi l'authentification windows et ASP.net
merci
khida
Messages postés
24
Date d'inscription
mardi 30 mai 2006
Statut
Membre
Dernière intervention
6 juillet 2009
18 juin 2007 à 16:26
18 juin 2007 à 16:26
pour maj d1 table
alter table "nom de la table" add nomuser varchar(30) not null default current_user
alter table "nom de la table" add nomuser varchar(30) not null default current_user
