Aide pour affichage disponibilites

Ca ne veut bien sûr pas dire qu'il ne faut pas
filtrer les données fournies par GET, mais que les filtes à appliquer
ne sont pas forcément les mêmes.

Ca me parait dangereux intrinsèquement. Par curiosité, quelles
différences pourrions nous envisager en se basant exclusivement sur ce
critère ?

Si on applique la règle :
- les données fournies en GET sont des données pour récupérer un
document ou une information
- les données fournies en POST sont des données qui sont envoyées au
serveur pour traitement et enregistrement

( cf protocole HTTP, c'est pas moi qui l'ai inventé )

Pour GET on se soucie juste d'un traitement qui s'assure de la
conformité des données avec ce que l'on attend, pas besoin de faire de
traitements spécifiques à l'enregistrement des informations.

Un exemple:
Pour les paramètres fournis par GET, on peut se permettre de faire un
strip_tags ou bien un mb_convert_encoding, pour les mêmes paramètres
fournis en POST, il faudrait filtrer les tags autorisés, ce qui est
beaucoup plus gourmand en ressources.

Ce n'est pas vous qui parliez de ne pas rajouter des traitements
inutiles qui complexifie le code dans un post de ce fil ?

Utiliser GET pour envoyer un formulaire ou pour faire autre chose que de
demander un document est une violation du protocole HTTP.

Vous nous citez le texte de la RFC qui dit que faire un formulaire en GET
est une violation du protocole HTTP, histoire qu'on rigole ?
(Indice: à quoi sert l'attribut method ?)

Sinon, merci d'arrêter de divaguer et de propager des erreurs.

Ah, aussi n'oubliez pas d'écrire à Google pour dire qu'ils violent HTTP
: bah oui ils font un formulaire d'interrogation, mais c'est du GET, ouh
les méchants.

Il est marrant de voir comment vous défendez ce protocole dans certaines
circonstances ( cf le cas rabattu du header Location ) et de voir
comment ça ne vous dérange pas de la violer dans d'autres circonstances.

C'est vous qui voyez des violations où il y en a pas. Plutôt que
d'essayer de faire coller le monde à vos vues (incorrectes), vous devriez
ouvrir votre horizon et voir ce qui se passe en vrai dans la nature...

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Ce genre de protection est du même niveau que de cacher la signature du
serveur web, du serveur mail ou de PHP, facilement contournable mais
faisant parti des pré-requis.

Ah... je ne me trompais pas alors en parlant alors de sentiment de
sécurité vs réelle sécurité à un autre endroit. Cacher ces données, cela
n'apporte strictement rien en terme de sécurité, peut-être juste le
sentiment de sécurité, donc la pire chose imaginable, pire que pas de
sécurité. On peut choisir de ne pas les présenter, mais c'est tout sauf
un choix en termes de sécurité.

En faisant la distinction entre les requêtes POST et GET, on sait déjà
que les variables ne doivent pas subir le même type de traitement, les

Bien sûr que si. *Toutes* les données venant de l'extérieur doivent
subir le même filtrage. Et si on est très rigoureux on incluera dans
l'extérieur, le SGBDR, et même l'OS.

données fournies par POST étant par définition ( cf protocole HTTP ) des
données non sûres.

Vous nous citez le passage du protocole HTTP qui dit que les données d'un
POST sont non sûres (ainsi que la définition de ce qu'on entend par sûr
dans ce contexte) ? Par opposition à celle d'un GET qui le seraient
j'imagine ?

Ca ne veut bien sûr pas dire qu'il ne faut pas
filtrer les données fournies par GET, mais que les filtes à appliquer ne
sont pas forcément les mêmes.

Bien sûr que si.

C'est vraiment terrible les failles que vous *créez* avec votre méthode
: il suffit de changer la méthode HTTP pour subitement être vulnérable
ou plus vulnérable à une attaque. L'horreur absolue.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Faire de la vraie sécurité, oui, pas de la mystification comme il est
proposé.

En matière de sécurité, je pense que Chris Shiflett, ne vous en
déplaise, est loin d'être un mystificateur.

La soumission d'un formulaire via POST est plus compliquée à faire à
l'insu de l'utilisateur que l'utilisation d'un web bug,

Si, via une faille, on peut ajouter n'importe quoi dans un document HTML,
et qu'on peut ajouter un web bug, on peut alors aussi ajouter un
formulaire et du javascript. Donc même faille, même attaque, même
niveau de complexité.

Je ne connais pas beaucoup de lecteurs de mail qui ont javascript
d'activé ( même outlook express ne l'a pas d'activé par défaut ), sans
compter les antivirus qui enlèvent le javascript des mails. Par contre,
on peu facilement exploiter un web bug sur un mail, la plupart affichent
les images sans rien demander.

Sans compter que lorsqu'un formulaire est soumis via POST, le navigateur
prévient l'utilisateur par défaut.

En faisant la distinction entre les requêtes POST et GET, on sait déjà
que les variables ne doivent pas subir le même type de traitement, les

Bien sûr que si. *Toutes* les données venant de l'extérieur doivent
subir le même filtrage. Et si on est très rigoureux on incluera dans
l'extérieur, le SGBDR, et même l'OS.

Certainement pas, toutes les données venant de l'extérieur doivent subir
un filtrage, mais le niveau de granularité ne doit certainement pas ête
le même. C'est d'une part ajouter un traitement inutile et d'autre part
se fermer d'une certaine souplesse.

Vous devez faire parti des gens qui applique htmlentities sur toutes les
données texte.

Cf mon exemple plus bas.

données fournies par POST étant par définition ( cf protocole HTTP ) des
données non sûres.

Vous nous citez le passage du protocole HTTP qui dit que les données d'un
POST sont non sûres (ainsi que la définition de ce qu'on entend par sûr
dans ce contexte) ? Par opposition à celle d'un GET qui le seraient
j'imagine ?

9.1.1 Safe Methods

Implementors should be aware that the software represents the user in
their interactions over the Internet, and should be careful to allow the
user to be aware of any actions they might take which may have an
unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD
methods SHOULD NOT have the significance of taking an action other than
retrieval. These methods ought to be considered "safe". This allows user
agents to represent other methods, such as POST, PUT and DELETE, in a
special way, so that the user is made aware of the fact that a possibly
unsafe action is being requested.


Si une méthode est supposée sûre pour l'utilisateur, il n'y a pas
d'intéret à vouloir transmettre d'autres données que des simple données
de demande de document ( à moins de vouloir tromper son visiteur ), les
traitements à faire sur les entrées sont donc plus radicales (
strip_tags ou mb_convert_encoding pour supprimer ou transformer du code
HTML par exemple ) alors que les données transmises par POST devront
subir un filtrage plus fin mais aussi plus dangereux pour le système.

Pourquoi se fatiguer à utiliser $_REQUEST, $_GET ou $_POST d'ailleurs
quand on peut mettre en register_global à on ?
C'est une excellente question à laquelle j'ai une réponse toute prête et

d'ailleurs le gars qui a écrit PHP aussi :
Le 1er octobre 2002 je disais ceci :
http://groups.google.com/group/fr.comp.lang.php/msg/13e64e15d2d8f24e

Et j'avais déjà dû sortir le même couplet sur fciwap, mais je n'ai pas
retrouvé en recherche rapide. En gros : register_globals en Off, c'est
de la connerie.

Vous citez là un post ou vous montrez une bien belle supériorité sur les
gens qui n'ont pas votre culture informatique, il n'y a vraiment pas de
quoi être fier.
Mais pas la peine de ranimer ce débat qui a été tranché par l'équipe de
dev de PHP.

Vous montrer là une bien mauvaise connaissance des CSRF. L'envoi des
données et bel et bien valide et les droits de la personne aussi ( id,
de session, cookie etc ... ) puisque la requête est envoyée par la
bonne personne avec les bons droits et c'est le but de la méthode.
Alors dans ce cas, ce n'est pas de rajouter un token qui changera quoi

que ce soit car s'il est transmis en get/post, l'id_session ou le token,
même combat. Le problème est plutôt que l'ajout de l'id_session est
automatique.

Sauf que le token est régénéré à chaque demande du formulaire, il n'est
donc pas possible d'utiliser un CSRF qui fatalement n'aura pas le même
token.

<CITE>
POST requests can also be forged, so do not consider a strict use of
$_POST to be sufficient protection.
</CITE>
Jamais dit le contraire.

Alors en quoi est-ce que vérifier que la requête http est bien du POST
est ***suffisant*** pour se protéger de ce type d'attaque ?

Vous pouvez citer le passage ou j'affirme que c'est suffisant. N'importe
quel développeur sait qu'une méthode n'est jamais suffisante en matière
de sécurité mais bel et bien une combinaison de méthodes toutes aussi
insatisfaisantes les unes que les autres.

Toutes les méthodes de protection sur le web sont contournables en
moins de 3 secondes,
Un id_session aléatoire de 40 chars de long non stocké dans un cookie ça

se pirate en 3 secondes ? Va falloir qu'on se fasse du soucis.

Il faut bien que vous le mettiez quelque part votre id des session, dans
l'URL je suppose, d'une part ça pose autant de problèmes que les cookies
de manière générale et d'autre part c'est autant vulnérable qu'un cookie
mais je ne vais pas vous faire l'affront de vous rappeler la littérature
sur le sujet.

Je suppose que vous n'en êtes quand même plus à coder vos formulaires
à partir de zéro à chaque fois mais que vous avez des libs qui vous
permettent des les générer et d'en valider les entrées.
Mauvaise supposition, changer de supposition. Quand on arrive chez un

client sur une appli web qui tourne depuis 5 ans, on commence pas par
dire "les mecs, vot' truc c'est de la merde, il vous faut *mes* libs".

Et bien, je suppose que les développeurs précédents en avaient, c'est
quand même pas bien compliqué que de modifier celles-ci.

Cette boutade est rafraîchissante de naïveté, on croirait entendre un
stagiaire au cours de sa première semaine en entreprise.

Rassurez vous, je suis en deuxième semaine.

Il va de soit
en effet qu'à chaque fois que j'arrive sur un projet, je commence par
faire la liste des autres prestataires et que le soir du premier jour je
dis à mon client "tous ceux là c'est des cons faut les virer". Et quand
en face de mes équipes j'ai un grand compte qui peut acheter ma boite ou
celle de mon client au petit déjeuner, je lui répond "tes équipes c'est
des brêles, change les moi". Réveil !!

On a toujours le choix de refuser un contrat lorsque les conditions de
travail ne conviennent pas à moins d'être un crève la faim qui ferait
tout pour quelques centimes d'euro.

Je conçois qu'au début de son activité on accepte un peu n'importe quoi
et dans n'importe quelles conditions ( on est tous un peu passer par là
aux temps de vaches maigres ), mais ne me dites pas que depuis le temps
que vous exercez vous ne pouvez pas vous permettre de refuser un contrat
dont les conditions sont à la limite de l'amateurisme.

Ce n'est pas parce que vous avez affaire à un grand compte que celui-ci
n'a pas pu faire des erreurs dans ses choix, les décideurs sont rarement
les plus compétents pour prendre des décisions techniques.

Qu'est-ce que ce que je (entre autres) dis de header(Location) vient à
faire avec le respect du protocole ? Je m'engage à vous envoyer une
bouteille de champagne si vous arrivez à trouver dans un article écrit
par moi depuis que je fréquente les newsgroups (c'est à dire fin 1996)
où j'ai fait une quelconque allusion au "respect du protocole http" ou à
une RFC quelconque pour justifier un point technique (1)

Oui bien sûr, ce n'est pas affirmer de manière aussi claire, mais quand
on dit que header("Location:" ) n'est pas fait pour tel type
d'utilisation, on se repose implicitement sur une spécification.

. Je m'en fout

des specs du protocole http (dont un certain nombre sont encore marquées
"experimental" depuis 1997...) d'ailleurs je ne les ai jamais lues et
c'est pas demain la veille que je les lirai.

Ca, on avait bien remarqué que vous vous en foutiez. Mais dire que vous
ne les avez jamais lues et dire que certaines sont marquées
expérimentales dans la même phrase dénote d'une bien mauvaise foie.

C'est quand même pratique les normes et les protocoles pour s'entendre
lorsque l'on travaille avec d'autres personnes.

Si on applique la règle :
- les données fournies en GET sont des données pour récupérer un
document ou une information
- les données fournies en POST sont des données qui sont envoyées au
serveur pour traitement et enregistrement

( cf protocole HTTP, c'est pas moi qui l'ai inventé )

Pour GET on se soucie juste d'un traitement qui s'assure de la
conformité des données avec ce que l'on attend, pas besoin de faire de
traitements spécifiques à l'enregistrement des informations.

Avec votre vision incorrecte (cf autre message où vous dites qu'un
formulaire ne doit pas faire de GET), vous croyez au final apparemment
qu'un GET ne concerne que des documents statiques.
Or ce n'est pas le cas : un moteur de recherche, recoit sa demande en GET,
et il fait une recherche, dans une base de données par exemple. Les
données doivent être donc filtrées, qu'il y ait enregistrement ou pas,
cela n'a rien à voir.
Car les données transmises sont *réutilisées* ailleurs (pour faire une
recherche SQL par exemple) et c'est là qu'est la faille, pas dans la
transmission.

Bref, vous ne courrez pas après la bonne faille je pense.

Un exemple:
Pour les paramètres fournis par GET, on peut se permettre de faire un
strip_tags ou bien un mb_convert_encoding, pour les mêmes paramètres
fournis en POST, il faudrait filtrer les tags autorisés,

Donc si je reprends une application développée avec vos principes, le
simple fait de changer le POST en GET me permet d'outrepasser certains
filtrages ? Grandiose !
Mais bien sûr vous allez me dire que c'est impossible parce que vous
utilisez $_POST ?

Ca revient un peu à «security through obscurity» votre affaire (la
sécurité est basée sur la méthode de transmission utilisée), comme
l'histoire de cacher les numéros de version. Tout le monde sait combien
de temps tiennent les solutions basées sur l'idée d'une boîte noire...

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Utiliser GET pour envoyer un formulaire ou pour faire autre chose que de
demander un document est une violation du protocole HTTP.

Vous nous citez le texte de la RFC qui dit que faire un formulaire en GET
est une violation du protocole HTTP, histoire qu'on rigole ?

Qui parle de ne pas faire de formulaire en GET ? Les formulaires n'ont
rien a voir avec le protocole HTTP. Notez bien la subtilité du
*envoyer* ( POST en anglais ) dans ma phrase.

C'est vrai que si on ne suis pas en détail la discussion, cette phrase
peut preter à confusion. J'aurais du préciser formulaire d'envoi de
données destinées à être données au serveur à des fin de traitement et
conservation, ca alourdit quand même un peu la phrase pour dire la même
chose.

(Indice: à quoi sert l'attribut method ?)

A vouloir à tout prix me contredire, vous en êtes à mélanger HTTP et HTML

Bonjour,

Vous citez là un post ou vous montrez une bien belle supériorité sur les
gens qui n'ont pas votre culture informatique, il n'y a vraiment pas de
quoi être fier.

Ah, ça y est, le chevalier en armure blanche se drappe dans sa dignité,
c'est en général comme ça que ça se termine quand les arguments
techniques sont arrivés à épuisement.

Le rapport avec la choucroute est ? Et acccessoirement, lisez plus loin,
vous comprendrez mon agacement que vous prenez pour de la supériorité.
Je rappelle aussi que je suis toujours intervenu sur fclphp ou son
ancêtre fciwap dans une optique d'application professionnelle, pas de
bidouille page-perso.

Mais pas la peine de ranimer ce débat qui a été tranché par l'équipe de
dev de PHP.
Et pourquoi ça ? Une connerie change de statut au cours du temps ou elle

reste une connerie ? (au fait, c'est pas moi qui ai lancé le sujet hein
;-)...)

Alors dans ce cas, ce n'est pas de rajouter un token qui changera quoi
que ce soit car s'il est transmis en get/post, l'id_session ou le token,
même combat. Le problème est plutôt que l'ajout de l'id_session est
automatique.
Sauf que le token est régénéré à chaque demande du formulaire, il n'est

donc pas possible d'utiliser un CSRF qui fatalement n'aura pas le même
token.

Un id_session valable 2 heures au maximum avec une fenêtre glissante
d'inactivité de 20 minutes ça suffit pas alors ?

Alors en quoi est-ce que vérifier que la requête http est bien du POST
est ***suffisant*** pour se protéger de ce type d'attaque ?

Vous pouvez citer le passage ou j'affirme que c'est suffisant.
1) donc comment pouvez vous continuer à dire qu'il faut le faire vu que

ça ne sera pas suffisant et qu'il faudra une méthode autre qui elle,
sera suffisante ?

2) Vous sous-entendez (ou affirmez carrément) qu'on peut (pire, qu'on
doit) traiter avec plus de confiance des données sous prétexte de leur
méthode de transmission. C'est *dangereux* (la pratique comme
l'affirmation).

Il faut bien que vous le mettiez quelque part votre id des session,
Oui: dans un champ HIDDEN exactement comme le token, c'est ce que je me

tue à vous répéter : il n'y a aucune différence entre l'id_session que
j'emploie et le token suggéré. Si on arrive à me piquer l'un, on
arrivera à me piquer l'autre.

l'URL je suppose, d'une part ça pose autant de problèmes que les cookies
de manière générale et d'autre part c'est autant vulnérable qu'un cookie
mais je ne vais pas vous faire l'affront de vous rappeler la littérature
sur le sujet.
Si, si, moi je suis preneur de ressources, ça m'intéresse, mais deux

remarques :
1) si l'attaquant réussit à me piquer mon id_session, de toutes façons,
c'est game over, kaput, finita la banana.
2) s'il réussit à me piquer mon id_session dans un champ HIDDEN ou dans
une url type A HREF, je serais curieux de savoir ce qui l'empêcherait de
me piquer mon token supplémentaire. Si on veut avoir des id_sessions
jetables (valables une fois) c'est lourd, mais on peut.

Et bien, je suppose que les développeurs précédents en avaient, c'est
quand même pas bien compliqué que de modifier celles-ci.
Allez-y, continuez à nous monter votre ignorance de la vraie vie. Allez

présenter la facture en j/h au client pour votre "c'est pas bien
compliqué", vous allez voir ce commment il va vous recevoir.

On a toujours le choix de refuser un contrat lorsque les conditions de
travail ne conviennent pas à moins d'être un crève la faim qui ferait
tout pour quelques centimes d'euro.
Parfait ! Allez-y en attaques personnelles, ça va arranger votre cas.

mais ne me dites pas que depuis le temps
que vous exercez vous ne pouvez pas vous permettre de refuser un contrat
dont les conditions sont à la limite de l'amateurisme.

Mais ça n'a rien à voir avec la choucroute ! Je travaille pour de très
grands comptes (en direct ou non) et c'est à pleurer de constater ce que
vous appelez **à juste titre** l'amateurisme ambiant (je dis plutôt
"médiocrité", mais c'est la même chose). Moi j'vous l'dit ma pauv'dame :
quand on voir c'qu'on voit et qu'on entend c'qu'on entend, on a raison
de penser ce qu'on pense.
Votre position qui est "mais foutez moi ces cons à la porte, on ira plus
vite de faire le boulot nous même correctement que de repasser derrière
à nettoyer leurs conneries" je la pense (voire, je la dis)
régulièrement, mais en pratique **ça ne marche pas comme ça**. Tiens pas
plus tard que ce matin, j'ai un système en face qui n'est pas foutu de
conserver mes références uniques parce qu'au delà de 16 caractères, il
tronque. Et pourtant le protocole (pas http, un truc financier) qu'on
doit respecter exige que cette référence me soit retournée strictement
inchangée. Alors je fais quoi ? Il y a des accords de plusieurs 100aines
de milliers d'euros sur ce projet, je refuse de faire des modifs chez
moi en disant "démerdez vous" ?

Pour revenir dans le sujet : il y a aussi le cas où les utilisateurs
veulent absoluemnt pouvoir changer le html *eux-mêmes* et le font
régulièrement. Bonjour le foutoir si on se met à seulement accepter
l'une des méthodes.

Ce n'est pas parce que vous avez affaire à un grand compte que celui-ci
n'a pas pu faire des erreurs dans ses choix,
Pas moi qui dirait le contraire, mais une fois que les contrats sont

signés avec des clauses de dédit pharaonesques, et qu'on arrive en phase
où tout part en peau de c... avec 6 mois de retard et il faut redresser
la situation on faut quoi ? On pleure ? Une belote ?

les décideurs sont rarement
les plus compétents pour prendre des décisions techniques.

Pas moi qui dirait le contraire.

Oui bien sûr, ce n'est pas affirmer de manière aussi claire, mais quand
on dit que header("Location:" ) n'est pas fait pour tel type
d'utilisation, on se repose implicitement sur une spécification.

Alors c'est ma faute, je me suis mal exprimé. Je veux dire que c'est
fait pour préparer des headers nécessaires, par exemple, à l'envoi d'un
fichier. Ca, oui, header() est *fait pour*.

Ca, on avait bien remarqué que vous vous en foutiez. Mais dire que vous
ne les avez jamais lues et dire que certaines sont marquées
expérimentales dans la même phrase dénote d'une bien mauvaise foie.
Récemment j'avais besoin de citer dans un doc de référence le numéro de

la rfc concernant les uploads http (pour travailler avec la lib curl).
Un coup de faqs.org et je tombe sur la bonne, dans le *titre* duquel se
trouve la date et "experimental". Je peux vous assurer que je n'ai pas
lu une seule ligne du reste du blabla. Ca m'a juste fait marrer de voir
"1997-experimental". Si elle a été "superseded" on la vire, si elle est
encore valide, on en change au moins son statut.

C'est quand même pratique les normes et les protocoles pour s'entendre
lorsque l'on travaille avec d'autres personnes.

Peu importe : sauf cas particuliers, mon application n'est pas censée
travailler avec autre chose qu'elle même (le code html qu'elle a
généré). Et sinon, tout ce que j'ai beson de savoir, c'est l'URL, la
liste des arguments, et les éventuelles restrictions idiotes (genre, il
faut que soit impérativement en POST) imposées par le développeur en face.
S'il fallait que tout le monde ait lu toutes les RFCs nécessaires à
faire du http avant d'écrire une ligne de html, "the world would be a
better place" , mais ce n'est pas le cas.

a++;
JG

Alors en quoi est-ce que vérifier que la requête http est bien du POST
est ***suffisant*** pour se protéger de ce type d'attaque ?
Vous pouvez citer le passage ou j'affirme que c'est suffisant.

1) donc comment pouvez vous continuer à dire qu'il faut le faire vu que

ça ne sera pas suffisant et qu'il faudra une méthode autre qui elle,
sera suffisante ?

Vous connaissez beaucoup de méthodes *suffisantes* en matière de
développement web ?

Je me tue à le répéter, chaque méthode prise seule n'est *jamais*
suffisante ( celui qui prétend le contraire est bien naïf ), c'est la
combinaison des méthodes qui accroit la sécurité et toute méthode qui
accroit celle ci est donc bonne à prendre.

2) Vous sous-entendez (ou affirmez carrément) qu'on peut (pire, qu'on
doit) traiter avec plus de confiance des données sous prétexte de leur
méthode de transmission. C'est *dangereux* (la pratique comme
l'affirmation).

Elles sont considérées plus sûres pour l'utilisateur. On ne doit donc
pas passer en GET des informations destinées à être traiter et
enregistrées par le système.

Non, on doit les traiter différemment, cf mon autre post ou je parle de
la granularité des traitements à effectuer.

Il faut bien que vous le mettiez quelque part votre id des session,
Oui: dans un champ HIDDEN exactement comme le token, c'est ce que je me

tue à vous répéter : il n'y a aucune différence entre l'id_session que
j'emploie et le token suggéré. Si on arrive à me piquer l'un, on
arrivera à me piquer l'autre.

Donc votre id de session n'est pas plus sécurisé qu'un id de session
passé en cookie et pose autant de problèmes.

l'URL je suppose, d'une part ça pose autant de problèmes que les cookies
de manière générale et d'autre part c'est autant vulnérable qu'un cookie
mais je ne vais pas vous faire l'affront de vous rappeler la littérature
sur le sujet.
Si, si, moi je suis preneur de ressources, ça m'intéresse, mais deux

remarques :
1) si l'attaquant réussit à me piquer mon id_session, de toutes façons,
c'est game over, kaput, finita la banana.
2) s'il réussit à me piquer mon id_session dans un champ HIDDEN ou dans
une url type A HREF, je serais curieux de savoir ce qui l'empêcherait de
me piquer mon token supplémentaire. Si on veut avoir des id_sessions
jetables (valables une fois) c'est lourd, mais on peut.

Vous confondez deux problèmes là.

Oui, votre id passé dans l'url ou par un champs hidden n'est pas
vulnérable au CSRF.

Mais ce système apporte autant de problèmes que de solutions :

1) il faut que toutes les pages lors de la session contiennent cet id,
adieu les pages statiques qui font perdre direct la session

2) Le référencement devient quasiment impossible pour un site public si
un id de session est passé dans toutes les URL, ne parlons même pas de
champs hidden qui demandent la validation d'un formulaire.

Il y a des cas ou on *doit* utiliser un cookie ne vous en déplaise et
dans ce cas, on est vulnérable au CSRF.

S'il fallait que tout le monde ait lu toutes les RFCs nécessaires à
faire du http avant d'écrire une ligne de html, "the world would be a
better place" , mais ce n'est pas le cas.

Toutes, ce n'est peut être pas la peine, mais ça ne ferait pas de mal
que des professionnel connaissent un minimum. J'irais même plus loin, il
serait bien que ceux qui font du HTML sachent un minimum ce qu'ils font
pour qu'on arrete de se retrouver avec des sites sont le design est
entiérement composé à base de tableaux etc .. mais ceci est un autre débat.