HttpSession login pwd et serializable

Version imprimable

14/09/2009, 18h40
r1-1024

HttpSession login pwd et serializable
Bonjour,
Afin d'éviter de faire n'importe quoi avant d'utiliser l' HttpSession, g qq questions.

-HttpSession fonctionne via les cookies, et identifie donc une session (id) avec un navigateur. Comment peut on vérifier que l'utilisateur autorise la création de cookies ?

-Qd un utilisateur se log (login+pwd) qu'est ce que je dois enregistrer dans le HttpSession pour l'identifier de façon sure ?
Code:

1 2 3 4 //A bannir session.setAttribute("login","Dupont"); session.setAttribute("pwd","secret");
-Si qq'1 accède à ses cookies, comment éviter qu'il usurpe son identité si le
HttpSession du servlet est toujour valide ?
En particulier si je sauvegarde l'id de l'utilisateur dans l'HttpSession.

-Comment peut on changer dynamiquement le temps de validité d'une session ?

-Les attributs de HttpSession ne sont pas "serializable". HttpSession et tous les objets mappés sont ils sauvegardé en RAM. Si tel est le cas comment éviter un OutOfMemory sur le servlet ?

Merci
15/09/2009, 16h10
r1-1024

Citation:

-Qd un utilisateur se log (login+pwd) qu'est ce que je dois enregistrer dans le HttpSession pour l'identifier de façon sure ?

Les attributs HttpSession restent côté serveur donc pas de pb.

Citation:

-Comment peut on changer dynamiquement le temps de validité d'une session ?

HttpSession.setMaxInactiveInterval()

Citation:

-Les attributs de HttpSession ne sont pas "serializable". HttpSession et tous les objets mappés sont ils sauvegardé en RAM. Si tel est le cas comment éviter un OutOfMemory sur le servlet ?

Il faut limiter le nombre d'attributs en RAM (sinon enregistrer les attributs en BD et les libérer avec un HttpSessionListener).

Le HttpSession sert-il à enregistrer les produits achetés sur un site marchand ?
Que se passe t-il si 1000 clients mettent dans leur cadi 1 million de produits ? :aie:

Citation:

-Si qq'1 accède à ses cookies, comment éviter qu'il usurpe son identité si le
HttpSession du servlet est toujour valide ?
En particulier si je sauvegarde l'id de l'utilisateur dans l'HttpSession.

L'id utilisateur ne sera pas accessible dans le cookie (puisqu'il reste côté serveur).

Mais effectivement on peut usurper l'identité d'un utilisateur une fois qu'il est connecté.

Alors voilà la question qui peut faire mal :
Comment le jsessionid est il généré ? :aie:

En d'autre termes est il possible de faire :
-je me connecte sur une boîte mail très connue.
-j'identifie la techno du serveur (comment est généré l'id & le cookie)
-je me déconnecte
-je change l'id dans le cookie (connaissant la techno je peux trouver un id valide, comme le FAM est très connu g de grande chances de tomber sur un id de session active)
-je me reconnecte
-je suis connecté sur le compte de qq'1 d'autre sans connaître son pwd.

:cfou:

Citation:

-HttpSession fonctionne via les cookies, et identifie donc une session (id) avec un navigateur. Comment peut on vérifier que l'utilisateur autorise la création de cookies ?

Je ne sais toujours pas.

Le but de tout ça étant de faire qq chose de sérieux.
15/09/2009, 18h22
r1-1024

Effectivement le HttpSession n'est absolument pas sécurisé :calim2:

Pour ceux que ça intéresse:
-On peut modifier les cookies de firefox dans le fichier sessionstore.js (évidement ça suffit pour trapper le HttpSession)
-Dans tomcat, les sessionids sont générés dans org.apache.catalina.session.ManagerBase.generateSessionId()
-Visiblement gmail rajoute des cookies certifiant l'id de session afin d'éviter l'usurpation (à vérifier plus sérieusement).

Si qq'1 à du retour sur les cookies servant à certifier un id de session, j'suis preneur.

En regardant mes cookies j'me suis aperçu que sur certain sites (c pas toujours le cas) j'ai un cookie UID (User ID) et un autre SID (Session ID).
Mais pas de signature certifiant les deux ?

Merci pour votre aide.
16/09/2009, 23h45
Alain Defrance

Bonjour,

Citation:

Envoyé par r1-1024

-HttpSession fonctionne via les cookies, et identifie donc une session (id) avec un navigateur.

Tu peut aussi passer par HttpServletResponse.encoreUrl() au cas ou le client ne supporte pas les cookies.

Citation:

Envoyé par r1-1024

Que se passe t-il si 1000 clients mettent dans leur cadi 1 million de produits ? :aie:

BOOM :aie:

Le mieux en terme de sécurité est tout de même de faire confiance à ce qui existe déjà.
JAAS ? :p
17/09/2009, 00h26
r1-1024

Hello,

encodeURL me renvoie l'url encodée avec le session id. Il faut que je transforme toutes les urls de mes pages à la mano ?

Dans la jdoc il est spécifié :

Citation:

For robust session tracking, all URLs emitted by a servlet should be run through this method. Otherwise, URL rewriting cannot be used with browsers which do not support cookies.

Ca veut dire qu'on devrait le faire pour toutes les URL :calim2:
Ca alourdi vachement le code. Mais si c'est ce qu'il faut faire...

De plus, comme je le disais plus haut, il faut absolument ajouter un UID en plus du SID (ou jsessionid) afin d'éviter une usurpation d'utilisateur une fois que le client s'est identifié.

J'pense alors qu'il faudrait s'inspirer d'une implémentation de encodeURL pour y rajouter le UID.

Merci pour l'info.

Citation:

BOOM :aie:

C'est bien ce que je pensais. Certains sites utilisent le HttpSession de façon abusive.

Citation:

Le mieux en terme de sécurité est tout de même de faire confiance à ce qui existe déjà.
JAAS ? :p

J'adore ce genre d'infos. :lahola:
Merci

Voilà un petit lien qui va probablement clore la discussion.
http://www.developpez.net/forums/d32...cation-tomcat/

Sinon pour le check des cookies (activation dans le navigateur), j'imagine qu'i faut faire un petit truc en javascript :roll: