Bonjour,

J'ai lu une partie de la documentation sur la fonction mail(), sur le hijack mail, est ce qu'il est necessaire de la proteger?

Merci

il faut surtout que tu sécurise ton header afin d'empêcher quelconque injection.

Salut,


Ta question n'est pas assez précise.

On ne protège pas une fonction
Mais des données ou une fonctionnalité.

Dans l'exemple que tu montre il y a une vérification des champs du formulaire pour éviter les spammeurs. Certain protection sont basic, comme le test sur le user agents qui ne sera pas indiqué sur des bots "entrée de gamme" (si je puis dire XD).
L'utilisation d'un jeton de validité pour le formulaire (token chez nos amis anglosaxon).
Le truc correspond à mettre une chaîne (aléatoire c'est mieux) dans un champs caché et tu stock celle ci dans une variable de session pour comparer à la validation du fomulaire. Quand tu as validé le formulaire tu supprime cette variable.
Avec sa tu evite tous les bots qui "copie" le formulaire et le réutilise.

Tous ceci pour éviter que l'on se serve de ton formulaire de contact (par exemple) pour spammeurs la terre entière (ou à défaut juste toi ).


@+

Il y a un plus d'explications ici. Comme le dit piotrowski-s le minimum est de protéger le header. Cela dit ce lien date un peu... et la solution d'utiliser "eregi" n'est plus d'actualité (car déprécié). Utilises plutôt preg_match à la place.

Merci AB je vais lire l'article

Le truc correspond à mettre une chaîne (aléatoire c'est mieux) dans un champs caché et tu stock celle ci dans une variable de session pour comparer à la validation du fomulaire. Quand tu as validé le formulaire tu supprime cette variable.
Avec sa tu evite tous les bots qui "copie" le formulaire et le réutilise.

Si j'ai bien compris:

<form ...>

<?php
$maClef = 'test'; // par exemple

$_SESSION['maclef'] = $maClef;
?>
<input type="hidden" name="clef" value="<?php echo $maClef; ?>" />

</form>

validation:

<?php

$maClef == $_SESSION['maclef'];
$clef = $_POST['clef'];

if($clef = $maClef)
{
// traitement du formulaire
$_SESSION['maclef'] = array();
}
else
{
echo 'tentative de spam';
}

Ouep c'est cela (à corriger cependant les = qui se transforment en == et inversement dans ton code de vérification, ainsi que la variable de type String qui est réinitialisée en array ).

Ouep c'est cela (à corriger cependant les = qui se transforment en == et inversement dans ton code de vérification

Un code a la main sans y penser

ainsi que la variable de type String qui est réinitialisée en array ).

tu veux dire la variable clef?

Tu peux utiliser uniqid pour générer un pseudo aléatoire unique (= $maClef)
Mais bon ça c'est pour éviter (au maximum possible) que des internautes puisse poster sans se connecter à ton site. C'est une protection supplémentaire mais qui ne doit pas te faire oublier la protection du header.

C'est une protection supplémentaire mais qui ne doit pas te faire oublier la protection du header.

Merci AB, C'est ma question principale, comment proteger le header?

Sur les champs constituant ton header tu peux appliquer une fonction supprimant les retours lignes par exemple :

function Protege_header($value) 
{
    $value = str_replace("\n", "", str_replace("\r", "", $value));
    return $value;
}

Sur les champs constituant ton header tu peux appliquer une fonction supprimant les retours lignes par exemple :

Mais deja dans les headers on utilise \r\n pour les separer, c'est ce que j'ai lu sur le net

Quand je disais "les champs" je parlais de ceux que tu récupère dans le formulaire, c'est à dire les variables issues du formulaire et qui te servent à faire les headers, évidemment pas des différentes lignes du header qu'on sépare par un "\n".
Lis le lien que je t'ai donné plus haut, tu vois bien qu'il se sert de eregi sur la variable $_POST["expediteur"] (vers la fin de l'article). Dans son exemple de code il fait un die s'il trouve "\n" ou "\r", mais bon plutôt qu'abandonner le srcipt et renvoyer une page blanche on peut simplement supprimer ces caractères. Et j'utilise aussi str_replace dans ma fonction parce que "eregi" est déprécié.

Oh oui, juste les champs du formulaire et qui existent dans les headers, je ferais un petit exemple et je reviens sur ce sujet