8722 sujets

Développement web côté serveur, CMS

Rebonjour,

excusez mon style alarmiste, mais le titre est vrai :

Je vous explique :
J'ai dans mon site php un formulaire de contact de l'admin sous forme de formulaire html+ JS de verif
On va l'appeler post.php

ce formulaire se post avec un bouton vers un formulaire send.php qui reprend les champs, les organise en mail et envois le message en mail à l'admin

Depuis trois mois je reçois des salves de 300 messages de spam (bon je m'en fous un peu, ils vont direct à la poubelle, mais je me dis qu'il faut que j'arrête ça. parce que ça pourrait concerner d'autres points du site plus sensibles que des mail à l'admin)

Ce matin j'ai décidé de m'y mettre et en installant un captcha, (voir ma question précédente) j'ai mis mon formulaire en carafe depuis 1 heure.

Nonobstant, je viens de voir que même avec mon formulaire en carafe, j'ai quand même reçu mon lot de spam du jour.
Je pense donc que ces braves gens (je ne dirais pas de gros mots ici), injecte directement leur post dans le fichier send.php sans passer par mon formulaire.

Avez-vous une solution ?

Je vous précise que je crois me souvenir qu'il y a un truc dans le php ini pour global je ne sais plus quoi, et que normalement il y a une raison pour qu'il soit ouvert parce que mon site louer-en-france.com est un vieux machin qui aura 10 ans l'an prochain et qu'il est très complexe (je n'ose dire bordelique...)

Donc si vous aviez un filtre php qui ne concerne que la page send.php pour ne pas qu'elle accepte tout de n'importe qui mais bien seulement de post.php via les boites ad'hoc je préfèrerai.

Merci de m'avoir compris

Cezig
benj a écrit :
Salut,
Si tu installe un captcha, tu n'auras plus de problème avec ton fichier post.php.


Ben non justement! puisque j'ai mis le fichier formulaire post.php en panne et que le spam passe quand même par mon send.php, c'est qu'il s'attaque direct à mon fichier send.php qui normalement est émulé par le formulaire post.php

Donc captcha ou pas ça passera
J'ai une faille de sécurité dans le fichier send.php on doit pouvoir injecter avec l'url ou je ne sait pas
Est-ce que vous croyez que c'est possible que mon "http://monsite.com/sendmail.php" puisse recevoir un formulaire de données post venant de "http//siteàlacon.com/post.php" ???
La vérification de ton captacha se fera coté serveur dans ton fichier post.php. Il n'y aura donc pas de problème.

a écrit :
Est-ce que vous croyez que c'est possible que mon "http://monsite.com/sendmail.php" puisse recevoir un formulaire de données post venant de "http//siteàlacon.com/post.php" ???
Ce n'est pas une faille de sécurité. Les données de ton formulaire arrivent surement en POST sur ton fichier post.php
Non mais attends y'en a un des deux (au moins) qui comprend pas l'autre

j'ai 2 pages php.

La 1 (formulaires) avec un bouton d'envoi

et

la 2 (sendmail) qui normalement recois de la 1

En ce moment j'ai plus de 1 mais la 2 envois encore du spam

POurquoi et comment ?
Il est très simple d'émuler un formulaire html (via un logiciel ou un petit programme) en envoyant directement les données à l'url qui est mentionnée dans la partie action de ta balise form.
Ce n'est pas une faille, cela fait partie intégrante du langage html et du protocole http.
Modérateur
Le souci du captcha est que l'accessibilité chute d'un coup ! Perso, je suis tombé sur des captcha illisible (le dev s'est un peu trop amusé sur imagick....) Je n'ai pas d'handicape particulier et souvent, je suis tombé sur des trucs illisibles. J'ai finalement vu de bons captcha. Cela reste tout de même rare.

Ma solution est plus transparente :
- Lorsque tu envoies l'affichage de ton formulaire :
* tu initialises un timestamp. Une personne physique ne peut pas remplir un formulaire en moins de 5 secondes et on est obligé de passer par le formulaire (temps d'affichage/temps d'envoi des données) Smiley cligne
* tu initialises un cookie au nom bizarre (nombre de visites/nombre de page vue/ page untel visitée -> un mix c'est peut être pas mal aussi) qui aura comme valeur un compteur ou un bolean (true/false). Si le user reposte une nouvelle fois, le cookie va calmer ses ardeurs.... Le temps du cookie sera à ton appréciation.
* il ne faut pas oublier d'ajouter un champ texte qui sera en display none !important. Le robot ne verra pas le display : none et remplira le champ.....

Espérant t'avoir aidé,
bon dev
Modifié par niuxe (24 Jun 2013 - 20:16)