formulaire
alainL
Un formulaire contient des menus déroulants . Lors des retours, je
reçois par défaut la première option affichée par la boite "menu" si pas
d'autre choix effectué par l'utilisateur.
Si "menu" propose "option1 / option 2 / option 3"
le retour me donne " menu : option 1" (ou 2 ou 3 si un choix est fait)
mais normalement jamais "menu :" tout seul même si le visiteur
n'effectue aucun choix et envoie le submit dès l'ouverture de la page
(j'ai testé ).
Mais voilà que je reçois de tps en tps des retours vides du type "
menu: "
Comment se fait-ce ??? :-)
Le formulaire est en html, traité avec php dans une autre page.
Il est en bas de cette page : http://autourdalos.fr/html/auteur.htm
--
Alain L
Olivier Miakinen
>
> Un formulaire contient des menus déroulants . Lors des retours, je
> reçois par défaut la première option affichée par la boite "menu" si pas
> d'autre choix effectué par l'utilisateur.
>
>
> Mais voilà que je reçois de tps en tps des retours vides du type "
> menu: "
>
> Comment se fait-ce ??? :-)
Première hypothèse : un visiteur utilise un navigateur qui ne se
comporte pas comme ceux que tu as testés.
Deuxième hypothèse : un spammeur tente de détourner ton formulaire en
lui envoyant des requêtes autres que celles que génèrerait un navigateur
normal.
Dans un cas comme dans l'autre, la parade est simple : si tu reçois des
données qui ne correspondent pas à ce que tu est prêt à accepter, tu
renvoies un message d'erreur (poli s'il y a une chance que cela vienne
d'un visiteur honnête, ou si tu n'es pas sûr de toi ; éventuellement
malpoli si tu es sûr et certain que c'est un spammeur).
alainL
Il me semble qu'il utilise Mozilla (code source du message)
Les codes de messages "normaux" et des "bizarres" sont d'ailleurs
quasiment identiques.
Mais son adresse n'apparait nulle part !
Tu parles d'un test lors du traitement php des données avant l'envoi
alors ?
--
Alain L
Olivier Miakinen
>>
>> Premiï¿œre hypothï¿œse : un visiteur utilise un navigateur qui ne se
>> comporte pas comme ceux que tu as testï¿œs.
>>
>> Deuxiï¿œme hypothï¿œse : un spammeur tente de dï¿œtourner ton formulaire en
>> lui envoyant des requï¿œtes autres que celles que gï¿œnï¿œrerait un navigateur
>> normal.
>>
>> Dans un cas comme dans l'autre, la parade est simple : si tu reï¿œois des
>> donnￜes qui ne correspondent pas ￜ ce que tu est prￜt ￜ accepter, tu
>> renvoies un message d'erreur (poli s'il y a une chance que cela vienne
>> malpoli si tu es sï¿œr et certain que c'est un spammeur).
>
> Il me semble qu'il utilise Mozilla (code source du message)
Ben ￜa, ￜ moins de pouvoir le contacter et qu'il te rￜponde (ce que ne
ferait bien sï¿œr pas un spammeur), tu ne peux pas le savoir. D'ailleurs
qu'appelles-tu le ￜ code source du message ￜ, s'agissant d'une requￜte
HTTP ?
Ce que je veux dire, c'est qu'avec WGET ou CURL par exemple on peut
envoyer tous les paramï¿œtres que l'on veut, y compris une chaï¿œne
contenant ￜ Mozilla ￜ dans HTTP_USER_AGENT.
> Les codes de messages "normaux" et des "bizarres" sont d'ailleurs
> quasiment identiques.
> Mais son adresse n'apparait nulle part !
Message ?... Adresse ???
Sois un peu plus clair dans les paramï¿œtres qui viennent de l'extï¿œrieur
et dont tu parles ici, car lￜ je ne comprends que dalle.
> Tu parles d'un test lors du traitement php des donnï¿œes avant l'envoi
> alors ?
Avant l'envoi ??? Si tu parles de l'envoi du formulaire, la rï¿œponse est
ￜvidemment non. Le moment oￜ il faut tester les paramￜtres, c'est ￜ la
rï¿œception de la requï¿œte qui te vient du visiteur lorsqu'il clique sur le
bouton de soumission du formulaire (ou lorsqu'il utilise WGET dans le
cas d'un spammeur qui essaye de dï¿œtourner ton formulaire).
alainL
> Le 07/04/2009 18:57, alainL a ï¿œcrit :
>>> Premiï¿œre hypothï¿œse : un visiteur utilise un navigateur qui ne se
>>> comporte pas comme ceux que tu as testï¿œs.
>>>
>>> Deuxiï¿œme hypothï¿œse : un spammeur tente de dï¿œtourner ton formulaire en
>>> lui envoyant des requï¿œtes autres que celles que gï¿œnï¿œrerait un navigateur
>>> normal.
>>>
>> Il me semble qu'il utilise Mozilla (code source du message)
>
> qu'appelles-tu le ￜ code source du message ￜ, s'agissant d'une requￜte
> HTTP ?
>
Ce que Thunderbird appelle ainsi :
_______________________________________________________________
From - Sun Apr 05 10:42:27 2009
X-Account-Key: account5
X-UIDL: 727.1238908572
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:
Received: from .............. (............. [xx.xxx.xx.xxx])
by relay-9m.club-internet.fr (Postfix) with ESMTP id xxxxxxxxx
for <mon....@club-internet.fr>; Sun, 5 Apr 2009 07:16:11 +0200 (CEST)
Received: from ............. (............... [xxx.x.x.x])
by .............. (x.xx.x/x.x.x) with ESMTP id xxxxxxxxxxxxxxxxx
for <mon...@club-internet.fr>; Sun, 5 Apr 2009 06:16:11 +0100
Received: (from autourdalos.fr@localhost)
by ............. (x.xx.x/x.xx.x/Submit) id xxxxxxxxx;
Sun, 5 Apr 2009 06:16:11 +0100
Date: Sun, 5 Apr 2009 06:16:11 +0100
Message-Id: <xxxxx...@xxxxxxxxxxxxx.uk>
To: mon...@club-internet.fr
Subject: depuis le site Autour d'Alos
From: Un visiteur <>
Reply-To:
Status:
X-Mmail: \Recent
X-M-Uid: xxx.xxxxxx
X-Antivirus: avast! (VPS 090404-0, 04/04/2009), Inbound message
X-Antivirus-Status: Clean
Origine:
Cherchait:
Pages:
Souhait:
Email:
Date: 5 04 09 ￜ 06h 16
____________________________________________________________________________
> Ce que je veux dire, c'est qu'avec WGET ou CURL par exemple on peut
> envoyer tous les paramï¿œtres que l'on veut, y compris une chaï¿œne
> contenant ￜ Mozilla ￜ dans HTTP_USER_AGENT.
>
OK
>> Tu parles d'un test lors du traitement php des donnï¿œes avant l'envoi
>> alors ?
>
> Avant l'envoi ??? Si tu parles de l'envoi du formulaire, la rï¿œponse est
> ￜvidemment non. Le moment oￜ il faut tester les paramￜtres, c'est ￜ la
> rï¿œception de la requï¿œte qui te vient du visiteur lorsqu'il clique sur le
> bouton de soumission du formulaire (ou lorsqu'il utilise WGET dans le
> cas d'un spammeur qui essaye de dï¿œtourner ton formulaire).
Oui, entre le "submit" du formulaire et le "mail($to,$message);" du
traitement, un bout de code du genre 'si $origine="" alors ecrire 'vous
n'avez pas rempli le champ'. Ca marchera aussi pour le spammeur ?
--
Alain L
Olivier Miakinen
>
>>> Il me semble qu'il utilise Mozilla (code source du message)
>>
>> HTTP ?
>
> Ce que Thunderbird appelle ainsi :
Hahaha ! C'est un troll ? Tu ne nous montre pas une requête HTTP, mais
le code source d'un courriel ! Qui plus est...
> _______________________________________________________________
> From - Sun Apr 05 10:42:27 2009
> X-Account-Key: account5
> X-UIDL: 727.1238908572
> X-Mozilla-Status: 0001
> X-Mozilla-Status2: 00000000
> X-Mozilla-Keys:
... si c'est ça qui te fait croire que le visiteur utilise Mozilla, j'ai
bien l'impression que tu te trompes doublement. Je crois moi que c'est
ton propre serveur web qui génère le message, et que c'est ton propre
client Thunderbird qui ajoute les entêtes X-Mozilla-* ! :-D
> [...] entre le "submit" du formulaire et le "mail($to,$message);" du
> traitement, un bout de code du genre 'si $origine="" alors ecrire 'vous
> n'avez pas rempli le champ'. Ca marchera aussi pour le spammeur ?
Le bout de code, c'est au tout début du programme PHP que tu dois le
mettre, et ce bout de code doit contrôler *toutes* les variables qui
viennent de l'extérieur avant d'envisager une seule seconde de faire
appel à une fonction aussi dangereuse que mail().
Je crois d'ailleurs que tu fréquentes le forum fr.comp.lang.php depuis
suffisamment longtemps pour avoir vu tous les conseils (toujours les
mêmes) que je donne à tous ceux qui viennent avec un script PHP faisant
appel à la fonction mail(). Alors s'il te plaît commence par relire une
petite demi-douzaine de ces messages, puis s'il te reste des questions
après cela viens soumettre ton script sur ledit forum.
Michael DENIS
> mettre, et ce bout de code doit contrï¿œler *toutes* les variables qui
> viennent de l'extï¿œrieur avant d'envisager une seule seconde de faire
> appel ￜ une fonction aussi dangereuse que mail().
Je crois que pour bien se protï¿œger, il faut commencer par bien
comprendre comment un spammeur peut utiliser un code mal sￜcurisￜ. Je ne
peux qu'encourager la lecture d'articles tels que celui-ci :
http://www.phpsecure.info/v2/article/MailHeadersInject.php
qui permet de mieux comprendre le problï¿œme de la fonction mail en
particulier, mais aussi finalement du risque liￜ ￜ des passages de
variables de faï¿œon gï¿œnï¿œrale.
--
Michaï¿œl DENIS