8722 sujets

Développement web côté serveur, CMS

Bonjour,

je reçois de mon formulaire un envoi vide - pas d'adresse mail, alors qu'elle est obligatoire dans le champ mail, et pas de message non plus, obligatoire aussi.
Whois me donne des informations sur l'adresse IP de l'expéditeur, notamment ça entre autres :
% Information related to '185.191.171.0 - 185.191.171.255'
% Abuse contact for '185.191.171.0 - 185.191.171.255' is 'bot@semrush.com'

Il y a aussi l'adresse postale complète, avec le numéro de téléphone de la société, mais peu importe. La question est : comment le formulaire a-t-il pu être envoyé, sans les champs obligatoires remplis ? Ces champs obligatoires ne servent à rien, alors ?
Modérateur
Bongota a écrit :
Bonjour,

je reçois de mon formulaire un envoi vide - pas d'adresse mail, alors qu'elle est obligatoire dans le champ mail, et pas de message non plus, obligatoire aussi.
Whois me donne des informations sur l'adresse IP de l'expéditeur, notamment ça entre autres :
% Information related to '185.191.171.0 - 185.191.171.255'
% Abuse contact for '185.191.171.0 - 185.191.171.255' is 'bot@semrush.com'

Il y a aussi l'adresse postale complète, avec le numéro de téléphone de la société, mais peu importe. La question est : comment le formulaire a-t-il pu être envoyé, sans les champs obligatoires remplis ? Ces champs obligatoires ne servent à rien, alors ?


Si c'est sur ton site perso, c'est normal. Avec une extension de navigateur (ou même sans) comme grease monkey ou même en envoyant des requêtes avec Curl depuis un terminal ou avec un script php/Python, je peux m'amuser à t'envoyer des milliers de requêtes. Rien ne vaut qu'une bonne validation de formulaire. Les require, ouais bof. Perso, je convertis ça en class et je valide mon code en front (mais pas que).

Au passage, tu verras un envoi vide. J'ai fait un test.

edit: Une des règles intrinsèques pour gérer un formulaire est de filtrer et valider les données entrantes. Les attributs require, ne sont là que pour éviter les requêtes serveur inutiles.
Modifié par niuxe (13 Nov 2023 - 03:35)
Modérateur
Bonjour,

Semrush est une société cotée en bourse dont le métier est entre autre de faire des recherches variées sur Internet à l'aide de robots.

Si la balise <form> du formulaire a un attribut action, il est possible (si ce n'est probable) que l'un des robots essaie juste de visiter l'url qui s'y trouve sans même chercher à remplir le formulaire. Et rien ne peut empêcher ça.

Amicalement,
Modérateur
parsimonhi a écrit :
Bonjour,

Semrush est une société cotée en bourse dont le métier est entre autre de faire des recherches variées sur Internet à l'aide de robots.

Si la balise &lt;form&gt; du formulaire a un attribut action, il est possible (si ce n'est probable) que l'un des robots essaie juste de visiter l'url qui s'y trouve sans même chercher à remplir le formulaire. Et rien ne peut empêcher ça.

Amicalement,


bien vu. Tu viens aussi de m'indiquer pourquoi il est parfois intéressant de ne pas mentionner l'attribut action. Merci Smiley smile
Bonjour,

merci pour toutes les réponses, je découvre encore d'autres problèmes sur ces formulaires, qui ne sont finalement pas si innocents. Le code html :
<span id="form" class="titresfoot">Formulaire de contact</span>
        <p>Les champs marqués d'une étoile' (*) sont obligatoires</p>
        
<form method="post" action="mail.php">

<label for="mailpost">Votre mail *</label>
<input type="text" id="mailpost" name="mailpost" required pattern="^(?!.*([.-])\1)(?!.*([.-])$)(?!.*[.-]$)(?!.*[.-]{2})[a-zA-Z0-9_%+-][a-zA-Z0-9._%+-]*@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$">

<label for="message">Entrez votre message: *</label>
<textarea id="message" name="message" cols=30 rows=3 required></textarea>

<input type="reset" id="reset" name="Reset all" size=30>
<input type="submit" name="submit" value="Send">

</form>


Le php (je l'ai réduit à sa plus simple expression mais c'est ce code qui est en service) :
<?php
$retour = mail('mon_adresse_mail@fournisseur.fr', 'Envoi depuis le formulaire', 
$_POST['message'],
$_POST['mailpost'], '');
    if ($retour);        
    }
}
?>

Modifié par Bongota (13 Nov 2023 - 07:53)
Salut,
Il faut bien comprendre que le traitement côté front c'est pour une question de confort pour l'utilisateur qui n'aura pas recharger la page pour voir le résultat de ses actions, en plus d'éviter des requêtes inutiles au serveur. La vraie sécurité reste toujours côté backend.

Donc, là en l'occurrence, il n'y a aucune protection car aucune vérification des données côté backend.
Modifié par Olivier C (13 Nov 2023 - 08:14)
Salut,
bien compris pour le backend. Il y a une (petite) protection sous forme de pot de miel. Je ne l'ai pas listée car le code allait être un peu long, avec du php et du JavaScript.
Peut-être est-elle inefficace.
Je vois le sujet mis comme résolu. À moins d'une erreur de ma part, ce n'est pas moi qui l'est mis. Le sujet n'est pas vraiment résolu, je travaille sur une protection en php et les conseils sont les bienvenus.
Bonne journée.
Modérateur
Bongota a écrit :

PS : Le problème étant de comment tester ces protections ?


Tu lances un server en local¹. Dans un terminal :

cd /repertoire/vers/test-formulaire/
php -S localhost:8000


ouvrir le navigateur à localhost:8000. Il est évident qu'il y a un index.php dans ce chemin (/repertoire/vers/test-formulaire/)

¹ le nec plus ultra est d'avoir un serveur nginx/apache en local avec le module php / rewrite installé / etc.
Modifié par niuxe (13 Nov 2023 - 17:14)