bonjour; besoin d’aide sur ce point…
ai mis une demo de site en prod protégé par un système de login simple
(salt & hash créé une session user, stocké dans la table sessions).
aujourd’hui lundi… marshal too long -> 500 internal; plus de 600 mille
sessions dans la table !
ça permet de mettre le doigt sur une vulnerabilité certaine; mais
comment retrouver la faille ?
un grand merci par avance si infos sur ce problème en particulier.
Il suffit de nettoyer la table des sessions (ou de nettoyer le
répertoire où sont stockés les fichiers de session). Genre supprimer
celles qui ont plus de 4 heures.
Sinon tu peux utiliser un plugin comme “limited session”
iprog.com | Code, projects, etc. pour nettoyer
automatiquement les sessions.
++
yk
Le 15 décembre 2008 11:38, Benjamin B.
[email protected] a écrit :
Benjamin B. wrote:
bonjour; besoin d’aide sur ce point…
ai mis une demo de site en prod protégé par un système de login simple
(salt & hash créé une session user, stocké dans la table sessions).
aujourd’hui lundi… marshal too long → 500 internal; plus de 600 mille
sessions dans la table !ça permet de mettre le doigt sur une vulnerabilité certaine; mais
comment retrouver la faille ?un grand merci par avance si infos sur ce problème en particulier.
Il n’y a pas de faille. Un simple Apache Bench qui se connecte en
permanence sur votre application, et une session est créée à chaque
fois. Une solution radicale: stocker la session dans un cookie. C’est ce
que nous utilisons sur notre site de vidéo à la demande.
–
Formation en informatique par VoD: http://www.digiprof.fr
ok fernando; ça me semble déjà plus clair !
je vais quand même creuser un peu plus tout ça.
un grand merci.
Fernando P. wrote:
Benjamin B. wrote:
bonjour; besoin d’aide sur ce point…
ai mis une demo de site en prod protégé par un système de login simple
(salt & hash créé une session user, stocké dans la table sessions).
aujourd’hui lundi… marshal too long → 500 internal; plus de 600 mille
sessions dans la table !ça permet de mettre le doigt sur une vulnerabilité certaine; mais
comment retrouver la faille ?un grand merci par avance si infos sur ce problème en particulier.
Il n’y a pas de faille. Un simple Apache Bench qui se connecte en
permanence sur votre application, et une session est créée à chaque
fois. Une solution radicale: stocker la session dans un cookie. C’est ce
que nous utilisons sur notre site de vidéo à la demande.–
Formation en informatique par VoD: http://www.digiprof.fr
Cookie ou pas cookie, t’es obligé de garder une table des sessions du
côté serveur, que ce soit sur digiprof.fr, novelys.com, kantena.com ou
feedback20.com
++
yk
Le 15 décembre 2008 12:10, Fernando P.
[email protected] a écrit :
Yann KLIS a écrit, le 12/15/2008 01:17 PM :
Cookie ou pas cookie, t’es obligé de garder une table des sessions du
côté serveur,
Recherche Google “Rails CookieStore”.
merci beaucoup pour cette réponse;
je vais passer du temps pour cette gestion de session à détruire.
Mais je m’interroge tjrs; en un jour, 600 000 session, c’est beaucoup
(il y aurait pu au max avoir une dizaine d’utilisateurs) !
Traditionnellement, une page de login renvoi vers une autre si
verification ok.
et ça laisse des traces dans les logs (redirect_to bla…, date, heure,
etc).
Cependant la dernière trace dans le log (produciton ici) date d’il y a 2
jours… là je me perds !
Yann KLIS wrote:
Il suffit de nettoyer la table des sessions (ou de nettoyer le
r�pertoire o� sont stock�s les fichiers de session). Genre supprimer
celles qui ont plus de 4 heures.Sinon tu peux utiliser un plugin comme “limited session”
iprog.com | Code, projects, etc. pour nettoyer
automatiquement les sessions.++
yk
Le 15 d�cembre 2008 11:38, Benjamin B.
[email protected] a �crit :
jadaa franklin wrote:
en gros ça riviendrait à changer totalement le système de stockage de
session (acgive record -> cookie);
c bien ça ?
Oui tout à fait. Attention ce n’est pas donné à tout le monde, les
informations stockée dans le cookie sont visibles (mais normalement non
modifiables à moins de cracker le code), et le site devient
potentiellement attaquable par cookie replay attack, donc le développeur
devra avoir cela en tête. A part ça c’est que du bonheur. Nous avons
choisit le “cookie based session store” sans trop d’hésitation.
Fernando P. wrote:
potentiellement attaquable par cookie replay attack, donc le développeur
devra avoir cela en tête. A part ça c’est que du bonheur. Nous avons
choisit le “cookie based session store” sans trop d’hésitation.
Il y a aussi la limitation du contenu. En effet, c’est limité à 4ko.
Mais cela finalement c’est pratique qu’il y ait cette limitation, car
une session trop grosse est un problème.
–
Cyril M.
J’avais relancé un peu vite par rapport au précédent post;
mais si l’on doit conserver une tables sessions;
comment prévenir un exces de creation de session ?
En fait, bon je n’ai pas encore testé, mais pq doit on conserver
la table sessions si cookie store ?
Yann KLIS wrote:
Cookie ou pas cookie, t’es oblig� de garder une table des sessions du
c�t� serveur, que ce soit sur digiprof.fr, novelys.com, kantena.com ou
feedback20.com++
yk
Le 15 d�cembre 2008 12:10, Fernando P.
[email protected] a �crit :
jadaa franklin wrote:
J’avais relancé un peu vite par rapport au précédent post;
mais si l’on doit conserver une tables sessions;
comment prévenir un exces de creation de session ?
En fait, bon je n’ai pas encore testé, mais pq doit on conserver
la table sessions si cookie store ?
Il n’y a plus de table dédiée aux sessions, l’affirmation était fausse.
Par contre ce qui se trouve dans le cookie est généralement une
références vers une donnée stockée dans une table, comme une entrée user
et un user_id dans le cookie. Le cookie session store ce n’est pas non
plus du tableless.
en gros ça riviendrait à changer totalement le système de stockage de
session (acgive record -> cookie);
c bien ça ?
Lionel B. wrote:
Yann KLIS a écrit, le 12/15/2008 01:17 PM :
Cookie ou pas cookie, t’es obligé de garder une table des sessions du
côté serveur,Recherche Google “Rails CookieStore”.
ok super, ça m’avais mis le doute; stocker la valeur de la session de la
table dans un cookie… jm’e disais, là ya un pb !
donc oui effectivement dans ce cas ce serait l’identifiant de
l’utilisateur qui serait stocké dans le cookie pour être lu/vérifié.
Bref, faut que je passe du temps dessus pour que ça prenne forme,
en tout cas merci beaucoup pour ces écalircissements.
Fernando P. wrote:
jadaa franklin wrote:
J’avais relancé un peu vite par rapport au précédent post;
mais si l’on doit conserver une tables sessions;
comment prévenir un exces de creation de session ?
En fait, bon je n’ai pas encore testé, mais pq doit on conserver
la table sessions si cookie store ?Il n’y a plus de table dédiée aux sessions, l’affirmation était fausse.
Par contre ce qui se trouve dans le cookie est généralement une
références vers une donnée stockée dans une table, comme une entrée user
et un user_id dans le cookie. Le cookie session store ce n’est pas non
plus du tableless.
Fernando P. a écrit :
potentiellement attaquable par cookie replay attack, donc le développeur
devra avoir cela en tête. A part ça c’est que du bonheur. Nous avons
choisit le “cookie based session store” sans trop d’hésitation.
Moi j’ai rencontré un problème avec les session dans les cookies, c’est
qu’il faut qu’elles fassent l’aller retour entre le serveur et le client
quand on veut écrire dedans. Si dans la session on stocke des infos voué
à être modifiée rapidement par la suite, ça passe pas.
Dans mon cas c’était un bouton “sélectionner/déselectionner”. Si
l’utilisateur sélectionnait plusieurs objet à la suite, la sélection
était prise en compte de façon très aléatoire.
Plus de problème depuis que la session est dans la db.
Sébastien Lamy a écrit, le 12/15/2008 07:28 PM :
qu’il faut qu’elles fassent l’aller retour entre le serveur et le client
quand on veut écrire dedans. Si dans la session on stocke des infos voué
à être modifiée rapidement par la suite, ça passe pas.
Dans mon cas c’était un bouton “sélectionner/déselectionner”. Si
l’utilisateur sélectionnait plusieurs objet à la suite, la sélection
était prise en compte de façon très aléatoire.
Plus de problème depuis que la session est dans la db.
Tu as mis à jour un symptôme d’un problème que tu n’as pas complètement
éliminé en passant ta session en DB.
Je m’explique : le problème vient du fait que tu as des requêtes qui
s’exécutent en simultanées (tes boutons de sélection tapent dans la
session avec de l’AJAX) et que le modèle de données que tu utilises ne
supporte pas les accès concurrents.
Lorsque tu as ta session en cookie, son contenu fait effectivement
l’aller-retour avec le serveur et si elle n’est pas revenue avant le
déclenchement de l’action suivante, tu as un problème car en réalité tu
peux avoir plusieurs versions de ta session valides à un moment donné
(en transit sur le réseau vers Rails, en cours de traitement par Rails,
en transit sur le réseau vers le navigateur) et c’est la dernière qui
revient au navigateur qui gagne (pas forcément la dernière envoyée et
pas forcément en ayant pris en compte toutes les modifications
intermédiaires).
Lorsque ta session est en base de données le même problème peut se
produire si tu utilises comme je le pense une liste d’id d’objets
sérialisée dans la session. Le problème se produit alors non pas au
niveau des versions de la session que le navigateur manipule, mais au
niveau des versions que tes mongrels/thin/processus Apache/… utilisent
(si tu as plusieurs traitements Rails simultanés, tu te retrouves encore
avec plusieurs versions de la session valides en même temps). Si tu fais
deux requêtes et que la première est plus longue à traiter que la
seconde, au moment où elle enregistrera la session en DB, elle annulera
la modification faite par la seconde. En gros ton problème va
réapparaître dès que ton serveur sera chargé…
La solution : ne pas stocker ces listes dans la session, mais dans un
modèle qui décrit l’association entre objet et user (éventuellement avec
une clef de session si tu veux pouvoir gérer une liste par session). En
utilisant un objet distinct en base pour chaque case cochée tu supportes
les accès concurrents : un objet détruit ou créé n’affecte pas les
autres.
C’est un problème extrêmement courant avec AJAX et les sessions, quel
que soit le framework ou la technique de stockage de la session. Le
CookieStore, encore une fois, a tendance à faire apparaître des bugs
qu’on ne soupçonne pas forcément.
Bon courage,
Lionel
Le 15 décembre 2008 12:10, Fernando a écrit :
Une solution radicale: stocker la session dans un cookie.
C’est vrai que c’est radical : c’est la solution par défaut dans
Rails.
C’est ce que nous utilisons sur notre site de vidéo à la demande.
formidable !
– Jean-François.
Lionel B. a écrit :
session (acgive record -> cookie);
choisit le “cookie based session store” sans trop d’hésitation.
Plus de problème depuis que la session est dans la db.Lorsque ta session est en base de données le même problème peut se
Bon courage,
Lionel
Merci beaucoup pour ce précieux dépistage, je ne vais donc pas tarder Ã
replonger le nez dans ce problème
On 16 déc, 01:46, “Jean-François Trân” [email protected] wrote:
Le 15 décembre 2008 12:10, Fernando a écrit :
Une solution radicale: stocker la session dans un cookie.
C’est vrai que c’est radical : c’est la solution par défaut dans
Rails.C’est ce que nous utilisons sur notre site de vidéo à la demande.
formidable !
Se méfier quand même des replay attack. Je n’ai pas regardé le code
depuis que ca a été releasé mais au moment où ca devrait être lancé il
n’y avait pas de mécanisme pour limiter la durée de vie de la session
dans le temps ou de la limiter à une ip.
Ce qui veut dire que si vous vous faites piquer votre cookie avec la
session de l’utilisateur loggé genre user_id:12, il est possible de la
rejouer autant de fois que l’on veut, du sso par cookie en gros.
L’expiry de la session n’est géré que par l’expiry du cookie ce qui ne
protège pas en cas de vol.
Si vous utilisez ce genre de storage il faut gérer un expiry par vous
même en profitant du fait qu’il n’est pas possible (très compliqué
plutôt) en revanche de forger les cookies.
Perso j’utilise pas car ca a tendance à hérisser les poils de techos
un peu pointilleux mais c’est une bonne solution simple et
performante.
Storage en DB je ne fais plus car ca pose trop de problème de locking
en cas de netoyage de 100aine de milliers de session. Par contre built-
in ca offre un moyen simple de connaitre le nombre de user
actuellement naviguant sur le site.
Storage Memcache très bien, performant, sécurisé, et gestion
automatique de l’expiration. Le problème il faut avoir un serveur
memcache et savoir comment ca marche car si c’est mal paramétré vous
risquez de voir vos sessions garbage collecté trop vite.
Renaud
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs