Reprise du message précédent :
<toutlemondelitTDWTF>
Le code de http://www.korea-dpr.com/
</toutlemondelitTDWTF>

Bah s'du DW quoi

[quotemsg%

Tiens ça me fait penser au collègue utilisateur de DW qui m'a soutenu récemment que les templates c'était de la merde parce-qu'on pouvait pas modifier visuellement les largeurs des éléments - passées par ses soins directement dans le code html, bien entendu.
Je l'ai pas jeté par la fenêtre, mais il est pas resté dans mon bureau à écouter ma réponse longtemps.

certes si t'as des conseils je prend aussi, bien sûr

Si je stock un booléen en session, celui-ci peut-être modifiable par une personne mal intentionnée ?

Oui

Mais il y accès facilement ou il faut qu'il "vole" la session comme je suis en train de le lire sur PHP Security ?
Parce que nos sessions sont déjà sécurisées.
Donc en fait la question plus spécifique serait :
sur une session sécurisé, est-ce que l'utilisateur actuel de la session peut en modifier son contenu ?

Non vu que c'est stocké coté serveur...

non

tu peux voler une session, mais pas la modifier depuis le client ( sauf si tu as des sciprt qui permettent de modifer et que la personen alml intentionné  exploite ses scripts)

Au temps pour moi, avec Rails les sessions sont stockées par défaut dans un cookie côté client (avec un système de protection, mais rien n'est infaillible).
 
Donc effectivement il ne peut pas librement modifier la session.

Dites, j'ai une requête ajax qui récupère les url des images situées dans une page passée en paramètre.
Le problème c'est que sur une page qui contient beaucoup d'images, la requête timeout au bout d'1mn tout pile...
ça peut venir de quoi? l'hébergeur? un paramètre pas configuré?

Dans ce cas c'est un cookie, pas une session  

Hum de mémoire sur Apache et la plupart des serveurs Web y a une directive qui donne le temps maximal d'exécution d'un script, souvent fixé entre 30 sec et 1 min par défaut, essaye de regarder vers là.

Merdum, c'est un mutualisé...
set_time_limit, ça peut passer si le safe mode est désactivé?

Cookie based session store  

edit: 'tin c'est le défaut depuis 2007

Dunno, je ne touche plus au PHP (ou du moins j'essaye) depuis que j'ai découvert Rails et surtout Django

Tu touches bien aux deux? Un petit comparatif?

Yep.

Une requête en moins sur la BD  

Si tu t'en sers que pour stocker le user_id, c'est pas mal. Sinon je vois pas la faille. Tout est crypté avec une clef sur le serveur, donc bon. Quel est la différence par rapport à stocker le session_id dans un cookie ?

C'est surtout zéro maintenance. Il faut faire gaffe aux cookies replay attack par contre.

Encore une fois, quel est la différence par rapport au stockage du hash de la session dans le cookie ?
Tu connais une fonctionnalité de remember-me qui ne soit pas attaquable en man-in-the-middle ?

on parlait de session avec totu ce que ça peut contenir comme données
 
pas juste d'un remember me

Site de commerce en ligne, avec order_id stocké en session.
 
Le user met 1 bouteille de Moët dans son panier et paye sa commande.
 
Une fois arrivé sur la page de paiement, order_id était en fait effacé de la session côté serveur, c'est fini le user ne peut plus rien faire avec.
 
Maintenant imagine que le user ait sauvegardé sa session stockée dans un cookie avant de payer, maintenant il peut faire un replay et rajouter d'autres bouteilles de Moët et du caviar à sa commande pour n'en payer qu'une. Donc il faut rajouter des vérifications si la commande a déjà été payé et des trucs comme ça dans le cas du cookie based session store
 
oscommerce posédait une faille similaire, j'en ai parlé sur leur forum et ils m'ont censuré car c'était un peu avant Noël...

Spa malin, fallait poster ça ici

Et ya plein d'autres cas, une session cryptée en cookie en fait on peut toujours la modifier, en la sauvegardant/rechargeant non ?

C'est un coup à lancer une guerre virtuelle ça
Plus sérieusement, je n'ai utilisé Rails que pour des petits projets persos pendant 1 an et demi, alors que j'utilise Django professionnellement depuis 2 ans, donc mon point de vue sera forcément biaisé. Surtout que je me tiens assez peu au courant des évolutions de Rails. Un des trucs que j'avais pas trop aimé notamment c'était que tous les helpeurs des vues utilisaient Prototype pour le JS à l'époque, or moi je voulais utiliser jQuery, du coup je me passais complètement de tout ça... ce qui est un peu dommage. Et je crois que c'est un des points qu'ils ont essayé d'améliorer dans Rails, c'est un peu plus "loose coupling", plus facile de changer l'une des briques.
 
Et après coup je préfère le Python au Ruby finalement, je le trouve un peu mieux structuré.
 
Mais les deux outils sont à mon avis assez formidable; du coup ça me créé limite problème pour la suite de mon "parcours professionnel", parce que je me vois plus du tout me refarcir du PHP pour faire du dev web maintenant, à tord peut être, les FW PHP ont du évoluer aussi, alors que c'est quand même bien plus demandé que le Python/Django... Bref

Avec Rails le cookie est crypté et une empreinte est générée avec une clé côté serveur, quand le cookie arrive une vérif est faite pour savoir s'il y a eu une modif maligne, c'est là qu'InvalidAuthenticityToken est raised.
 
C'est théoriquement crackable. Mais à part les chinois avec leur super calculateur Jaguar, ça risque de prendre un peu de temps, les dév considèrent que c'est sécurisé.
 
Par contre le contenu de la session dans le cookie est lisible en clair.

Oui c'est un peu chiant, mais des plugins existe pour utiliser jquery (ou autre) en lieu et place de proto, et dans Rails 3 il paraît que c'est découplé, mais j'ai pas encore regardé. En même temps une des forces de rails c'est que c'est opinionated, parce que trop de customisabilité c'est lourd.
 
Que ce soit Rails ou django, c'est un bon choix.

Heuu OK mais si ils ne sont pas basés sur des nonces ou des timestamps ça empêche pas les replays.

Oui je sais que c'est replayable puisque je l'ai démontré juste au-dessus.
 
Perso je considère que tout user input est potentiellement une attaque, donc je vérifie tout ce qui rentre, valeurs dans les cookies incluses

Si c'est replayé t'as aucun moyen de vérifier...

Sauf que le problème du replay c'est quand t'as une interception et que ton intercepteur a soudainement accès complet au compte et à l'historique d'un autre utilisateur (ou plusieurs)

Même si la session est sauvée en db elle reste interceptable, donc ça c'est un autre problème.
 
Pour détecter un replay dans le cas d'une commande: au moment où le user atteint la page des boutons de paiement, je mets à jour order.state="pending", donc s'il tente de rajouter des articles et que le state est à "pending" ou "paid" c'est qu'il triche Après c'est au cas par cas pour d'autres fonctionnalités.

Bon ... ça me semble être un bon début (ça chie un peu si on va trop vite, faut que je règle ça ; edit : normalement c'est bon) :

http://www.byscripts.info/assets/bylight/test3.php

Question Apache2: quand je set HeaderName, le <h1>Index of /mon/dir/bla/foo/bat</h1> n'est plus inclus; une idée de comment je peux l'avoir, tout en ayant un "include" comme headername, en haut de page ? (et pas en bas de page comme ReadmeName)
edit: hop, un ptit coup de .shtml et c'est réparé:

cfr. http://howto.unixdev.net/dirlist.html

edit: dans la meme veine, le IndexOptions +VersionSort ne semble pas trier "3.6" devant "3.6.1", ou c'est moi ?

 
Chépa
 
J'ai vu ça ici : http://www.sikker.com.ar/
Et là : http://web.enavu.com/demos/spotlight/
 
Me suis dit que l'effet était sympa et j'avais envie d'essayer de le faire avec Mootools

1000