bonjour à tous,
J'ai cru lire dans un post qq part ici que $_REQUEST pouvait mettre à mal la
sécurité.
Qu'en est-il exactement ? ( j'ai un peu tendance à l'utiliser...
beaucoup ). Je pensais que les superglobales accroissaient le niveau de la
sécurité.
merci.
Thibaut Allender , le 29 mai 2004 17:04:54, écrivait ceci:
Mais de même, si tu remplaces par if($_COOKIES['authenticate']==1) il suffit de modifier le cookie... Donc il n'y a pas plus de sécurité en écrivant ça qu'en écrivant if($_REQUEST['authenticate']==1) je dirais même que justement, on aura plus tendance à détecter cette **faille** de sécurité de conception (on ne fait pas plus confiance au contenu d'un cookie qu'à une variable arrivant d'un formulaire) en lisant qu'on est en train de faire confiance à une variable de _REQUEST qui indique bien la provenance du monde extérieur (donc potentiellement traffiquée).
d'autant plus qu'il faut savoir que la variable s'appelle "authenticate" sans access aux sources, bon courage ;)
Ah bon ?
alors que dans le cookie, on voit clairement son nom
Heuu que ce soit transmis en COOKIE, GET ou en POST on voit aussi très clairement le nom...
Exemple, ton formulaire de contact (j'ai mis une adresse invalide exprès pour que ca ne poste pas) me donne :
La j'ai non seulement le nom de la varibale du cookie mais également sa valeur (même pas besoin d'aller fouiller). En plus ca me le rebalance au lieu de le relire :-/...
Mais (et c'est la le plus intéréssant), j'ai aussi ce que j'ai transmis par ton formulaire : Content-Type: application/x-www-form-urlencoded Content-Length: 118 |_nom=Laurent& |_email=laurent-chez-alussian.org& |_objet=test&message=j%27envois+des+donn%E9es+via+ton+formulaire& |_submitted=1
Bref pas hyper difficie de voir ce qui se *trame* :-)
Thibaut Allender <use_contact_form_on_web_site@n.o.s.p.a.m.capsule.org>, le
29 mai 2004 17:04:54, écrivait ceci:
Mais de même, si tu remplaces par if($_COOKIES['authenticate']==1) il
suffit de modifier le cookie... Donc il n'y a pas plus de sécurité en
écrivant ça qu'en écrivant if($_REQUEST['authenticate']==1) je dirais
même que justement, on aura plus tendance à détecter cette **faille** de
sécurité de conception (on ne fait pas plus confiance au contenu d'un
cookie qu'à une variable arrivant d'un formulaire) en lisant qu'on est
en train de faire confiance à une variable de _REQUEST qui indique bien
la provenance du monde extérieur (donc potentiellement traffiquée).
d'autant plus qu'il faut savoir que la variable s'appelle "authenticate"
sans access aux sources, bon courage ;)
Ah bon ?
alors que dans le cookie, on voit clairement son nom
Heuu que ce soit transmis en COOKIE, GET ou en POST on voit aussi très
clairement le nom...
Exemple, ton formulaire de contact (j'ai mis une adresse invalide exprès
pour que ca ne poste pas) me donne :
La j'ai non seulement le nom de la varibale du cookie mais également sa
valeur (même pas besoin d'aller fouiller). En plus ca me le rebalance au
lieu de le relire :-/...
Mais (et c'est la le plus intéréssant), j'ai aussi ce que j'ai transmis par
ton formulaire :
Content-Type: application/x-www-form-urlencoded
Content-Length: 118
|_nom=Laurent&
|_email=laurent-chez-alussian.org&
|_objet=test&message=j%27envois+des+donn%E9es+via+ton+formulaire&
|_submitted=1
Thibaut Allender , le 29 mai 2004 17:04:54, écrivait ceci:
Mais de même, si tu remplaces par if($_COOKIES['authenticate']==1) il suffit de modifier le cookie... Donc il n'y a pas plus de sécurité en écrivant ça qu'en écrivant if($_REQUEST['authenticate']==1) je dirais même que justement, on aura plus tendance à détecter cette **faille** de sécurité de conception (on ne fait pas plus confiance au contenu d'un cookie qu'à une variable arrivant d'un formulaire) en lisant qu'on est en train de faire confiance à une variable de _REQUEST qui indique bien la provenance du monde extérieur (donc potentiellement traffiquée).
d'autant plus qu'il faut savoir que la variable s'appelle "authenticate" sans access aux sources, bon courage ;)
Ah bon ?
alors que dans le cookie, on voit clairement son nom
Heuu que ce soit transmis en COOKIE, GET ou en POST on voit aussi très clairement le nom...
Exemple, ton formulaire de contact (j'ai mis une adresse invalide exprès pour que ca ne poste pas) me donne :
La j'ai non seulement le nom de la varibale du cookie mais également sa valeur (même pas besoin d'aller fouiller). En plus ca me le rebalance au lieu de le relire :-/...
Mais (et c'est la le plus intéréssant), j'ai aussi ce que j'ai transmis par ton formulaire : Content-Type: application/x-www-form-urlencoded Content-Length: 118 |_nom=Laurent& |_email=laurent-chez-alussian.org& |_objet=test&message=j%27envois+des+donn%E9es+via+ton+formulaire& |_submitted=1
Thibaut Allender , le 29 mai 2004 22:33:43, écrivait ceci:
Bref pas hyper difficie de voir ce qui se *trame* :-)
j'ai jamais dit le contraire mais comme tu m'as mal compris,
Oui apparement.
tu essayes de demontrer qq chose que je sais deja :)
J'me disais aussi... Je trouvais bizzare venant de toi :-)
ceci dit, en GET tu ne pouvais pas valider le formulaire parce que j'utilise les variables $_POST ;))
J'ai vu ca quand j'ai fais mon test en GET, les données que j'avais mises ne se pas remise dans le formu.
Remarque dans ce cas précis (formulaire de contact), il y a un avantage de passer par $_POST : Éviter de traiter les liens avec les param qui se promènenent partout (si si j'en ai vu qui jouaient à ca et qui s'amusaient à les envoyer par mail ou les référencer dans un moteur de recherche). C'est un des rares cas (exception faite de $_FILES) ou j'utilise $_POST plutôt que $_REQUEST.
Thibaut Allender <use_contact_form_on_web_site@n.o.s.p.a.m.capsule.org>, le
29 mai 2004 22:33:43, écrivait ceci:
Bref pas hyper difficie de voir ce qui se *trame* :-)
j'ai jamais dit le contraire mais comme tu m'as mal compris,
Oui apparement.
tu essayes de demontrer qq chose que je sais deja :)
J'me disais aussi... Je trouvais bizzare venant de toi :-)
ceci dit, en GET tu ne pouvais pas valider le formulaire parce que
j'utilise les variables $_POST ;))
J'ai vu ca quand j'ai fais mon test en GET, les données que j'avais mises
ne se pas remise dans le formu.
Remarque dans ce cas précis (formulaire de contact), il y a un avantage de
passer par $_POST : Éviter de traiter les liens avec les param qui se
promènenent partout (si si j'en ai vu qui jouaient à ca et qui s'amusaient
à les envoyer par mail ou les référencer dans un moteur de recherche).
C'est un des rares cas (exception faite de $_FILES) ou j'utilise $_POST
plutôt que $_REQUEST.
Thibaut Allender , le 29 mai 2004 22:33:43, écrivait ceci:
Bref pas hyper difficie de voir ce qui se *trame* :-)
j'ai jamais dit le contraire mais comme tu m'as mal compris,
Oui apparement.
tu essayes de demontrer qq chose que je sais deja :)
J'me disais aussi... Je trouvais bizzare venant de toi :-)
ceci dit, en GET tu ne pouvais pas valider le formulaire parce que j'utilise les variables $_POST ;))
J'ai vu ca quand j'ai fais mon test en GET, les données que j'avais mises ne se pas remise dans le formu.
Remarque dans ce cas précis (formulaire de contact), il y a un avantage de passer par $_POST : Éviter de traiter les liens avec les param qui se promènenent partout (si si j'en ai vu qui jouaient à ca et qui s'amusaient à les envoyer par mail ou les référencer dans un moteur de recherche). C'est un des rares cas (exception faite de $_FILES) ou j'utilise $_POST plutôt que $_REQUEST.
Thibaut Allender
tu essayes de demontrer qq chose que je sais deja :)
J'me disais aussi... Je trouvais bizzare venant de toi :-)
j'en rougis presque :)
Remarque dans ce cas précis (formulaire de contact), il y a un avantage de passer par $_POST : Éviter de traiter les liens avec les param qui se promènenent partout (si si j'en ai vu qui jouaient à ca et qui s'amusaient à les envoyer par mail ou les référencer dans un moteur de recherche).
des liens avec params get qui provoquent la soumission du form de contact ? roohh, c'est vicieux ca
C'est un des rares cas (exception faite de $_FILES) ou j'utilise $_POST plutôt que $_REQUEST.
oui enfin, tu fais une petite page avec un form post, et un submit automatique en javascript, tu peux aussi t'amuser a faire ch*** le monde de la meme maniere et si tu t'y connais un peu en php, tu peux meme generer une requete post avec les sockets ou curl...
tout ca pour dire que la sécurité du $_POST, c'est vraiment bidon, meme si effectivement, comme tu le dis ici, ca permet de rendre un tout petit peu plus difficile la vie des emmerdeurs
tu essayes de demontrer qq chose que je sais deja :)
J'me disais aussi... Je trouvais bizzare venant de toi :-)
j'en rougis presque :)
Remarque dans ce cas précis (formulaire de contact), il y a un avantage de
passer par $_POST : Éviter de traiter les liens avec les param qui se
promènenent partout (si si j'en ai vu qui jouaient à ca et qui s'amusaient
à les envoyer par mail ou les référencer dans un moteur de recherche).
des liens avec params get qui provoquent la soumission du form de contact ?
roohh, c'est vicieux ca
C'est un des rares cas (exception faite de $_FILES) ou j'utilise $_POST
plutôt que $_REQUEST.
oui enfin, tu fais une petite page avec un form post, et un submit
automatique en javascript, tu peux aussi t'amuser a faire ch*** le monde
de la meme maniere
et si tu t'y connais un peu en php, tu peux meme generer une requete
post avec les sockets ou curl...
tout ca pour dire que la sécurité du $_POST, c'est vraiment bidon, meme
si effectivement, comme tu le dis ici, ca permet de rendre un tout petit
peu plus difficile la vie des emmerdeurs
tu essayes de demontrer qq chose que je sais deja :)
J'me disais aussi... Je trouvais bizzare venant de toi :-)
j'en rougis presque :)
Remarque dans ce cas précis (formulaire de contact), il y a un avantage de passer par $_POST : Éviter de traiter les liens avec les param qui se promènenent partout (si si j'en ai vu qui jouaient à ca et qui s'amusaient à les envoyer par mail ou les référencer dans un moteur de recherche).
des liens avec params get qui provoquent la soumission du form de contact ? roohh, c'est vicieux ca
C'est un des rares cas (exception faite de $_FILES) ou j'utilise $_POST plutôt que $_REQUEST.
oui enfin, tu fais une petite page avec un form post, et un submit automatique en javascript, tu peux aussi t'amuser a faire ch*** le monde de la meme maniere et si tu t'y connais un peu en php, tu peux meme generer une requete post avec les sockets ou curl...
tout ca pour dire que la sécurité du $_POST, c'est vraiment bidon, meme si effectivement, comme tu le dis ici, ca permet de rendre un tout petit peu plus difficile la vie des emmerdeurs
Thibaut Allender , le 30 mai 2004 03:05:55, écrivait ceci:
Remarque dans ce cas précis (formulaire de contact), il y a un avantage de passer par $_POST : Éviter de traiter les liens avec les param qui se promènenent partout (si si j'en ai vu qui jouaient à ca et qui s'amusaient à les envoyer par mail ou les référencer dans un moteur de recherche).
des liens avec params get qui provoquent la soumission du form de contact ? roohh, c'est vicieux ca
Oui hein ? Bon c'est vite fait de s'en prémunir (changement du nom d'un param par ex) mais bon, encore faut il en trouver la cause la première fois que ca t'arrive (quand tu vois un googlebot, t'as capté).
C'est un des rares cas (exception faite de $_FILES) ou j'utilise $_POST plutôt que $_REQUEST.
oui enfin, tu fais une petite page avec un form post, et un submit automatique en javascript, tu peux aussi t'amuser a faire ch*** le monde de la meme maniere et si tu t'y connais un peu en php, tu peux meme generer une requete post avec les sockets ou curl...
Sauf qu'avec ce genre de méthodes, tu n'as plus une multitude d'IP mais une seule et avec une seule IP, on peu jouer...
Thibaut Allender <use_contact_form_on_web_site@n.o.s.p.a.m.capsule.org>,
le 30 mai 2004 03:05:55, écrivait ceci:
Remarque dans ce cas précis (formulaire de contact), il y a un
avantage de passer par $_POST : Éviter de traiter les liens avec les
param qui se promènenent partout (si si j'en ai vu qui jouaient à ca
et qui s'amusaient à les envoyer par mail ou les référencer dans un
moteur de recherche).
des liens avec params get qui provoquent la soumission du form de
contact ? roohh, c'est vicieux ca
Oui hein ? Bon c'est vite fait de s'en prémunir (changement du nom d'un
param par ex) mais bon, encore faut il en trouver la cause la première fois
que ca t'arrive (quand tu vois un googlebot, t'as capté).
C'est un des rares cas (exception faite de $_FILES) ou j'utilise
$_POST plutôt que $_REQUEST.
oui enfin, tu fais une petite page avec un form post, et un submit
automatique en javascript, tu peux aussi t'amuser a faire ch*** le
monde de la meme maniere
et si tu t'y connais un peu en php, tu peux meme generer une requete
post avec les sockets ou curl...
Sauf qu'avec ce genre de méthodes, tu n'as plus une multitude d'IP mais une
seule et avec une seule IP, on peu jouer...
Thibaut Allender , le 30 mai 2004 03:05:55, écrivait ceci:
Remarque dans ce cas précis (formulaire de contact), il y a un avantage de passer par $_POST : Éviter de traiter les liens avec les param qui se promènenent partout (si si j'en ai vu qui jouaient à ca et qui s'amusaient à les envoyer par mail ou les référencer dans un moteur de recherche).
des liens avec params get qui provoquent la soumission du form de contact ? roohh, c'est vicieux ca
Oui hein ? Bon c'est vite fait de s'en prémunir (changement du nom d'un param par ex) mais bon, encore faut il en trouver la cause la première fois que ca t'arrive (quand tu vois un googlebot, t'as capté).
C'est un des rares cas (exception faite de $_FILES) ou j'utilise $_POST plutôt que $_REQUEST.
oui enfin, tu fais une petite page avec un form post, et un submit automatique en javascript, tu peux aussi t'amuser a faire ch*** le monde de la meme maniere et si tu t'y connais un peu en php, tu peux meme generer une requete post avec les sockets ou curl...
Sauf qu'avec ce genre de méthodes, tu n'as plus une multitude d'IP mais une seule et avec une seule IP, on peu jouer...
