Sécurisation formulaire de contact

[Kilroy]

Après avoir constaté que mes formulaires étaient utilisés comme relais pour du SPAM, j'ai pris les choses en main et j'ai mis en place une vérification des éléments saisis dans les champs par PHP.

Après avoir lu les conseils de ce document , j'ai donc interdit les sauts de lignes dans tous les champs de mes formulaires qui classiquement en comptent trois : nom, email, message

Je filtre les caractères :

\r

\n

%0A

%0D

0x0A

0x0D

Pour les champs nom et email, pas de problème.

Par contre, dans le champ message, ça empêche mes visiteurs de mettre des sauts de ligne dans leur message. Logique, mais gênant pour eux !

Comment faire ? Bloquer le contenu du champ 'message' est il bien nécessaire ? Des headers peuvent ils être injectés à ce niveau ?

[Leonick]

Comment faire ? Bloquer le contenu du champ 'message' est il bien nécessaire ? Des headers peuvent ils être injectés à ce niveau ?

oui

j'utilise ça, c'est perfectible encore je pense,

function removeHack($Xstring) {
$forbidden_words=array(
   "'from:'i"=>"!from:!",
   "'subject:'i"=>"!subject:!",
   "'bcc:'i"=>"!bcc:!",
   "'To:'i"=>"!To:!",
   "'CC:'i"=>"!CC:!",
   "'mime-version:'i"=>"!mime-version:!",
   "'base64'i"=>"base_64",
   "'content-type:'i"=>"!content-type:!",
   "'content-transfer-encoding:'i"=>"!content-transfer-encoding:!",
   "'content-disposition:'i"=>"!content-disposition:!",
   "'content-location:'i"=>"!content-location:!",
   "'include'i"=>"!include!",
   "'<script'i"=>"<script",
   "'</script'i"=>"</script",
   "'javascript'i"=>"!javascript!",
   "'embed'i"=>"!embed!",
   "'iframe'i"=>"!iframe!",
   "'refresh'i"=>"!refresh!",
   "'onload'i"=>"!onload!",
   "'onstart'i"=>"!onstart!",
   "'onerror'i"=>"!onerror!",
   "'onkey'i"=>"!onkey!",
   "'onmouse'i"=>"!onmouse!",
   "'document\.cookie'i"=>"!document.cookie!",
   "'jscript'i"=>"!jscript!",
   "'vbscript'i"=>"!vbscript!",
   "'pearlscript'i"=>"!pearlscript!",
   "''i"=>chr(39),
   "''i"=>chr(39),
   "''i"=>chr(34),
   "''i"=>chr(34),
   "''i"=>"&_#",
   "'<textarea'i"=>"<textarea",
   "'</textarea'i"=>"</textarea",
   "'<style'i"=>"<style",
   "'<body'i"=>"<body",
   "'<object'i"=>"<object",
   "'\<\?php'i"=>"<?php",
   "'</'i"=>"</",
   "'\<\?'i"=>"<?",
   "'\?\>'i"=>"?>",
   "'\<\%'i"=>"<%",
   "'\%\>'i"=>"%>");
   $Xstring=preg_replace(array_keys($forbidden_words),array_values($forbidden_words), $Xstring);
  return($Xstring);
}

[_seb]

Donc votre logique est 'on laisse tout passer sauf ...'

pas très fiable, ça suppose de connaitre toutes les failles de sécurité, comment elle marchent, ce que va taper le méchant ...

Une logique plus prudente est 'on ne laisse rien passer sauf ...' ; les points de suspensions étant a remplacer par les caractères alphanumérique, et quelques caractères de ponctuations triés sur le volet.

[Leonick]

Donc votre logique est 'on laisse tout passer sauf ...'

pas très fiable, ça suppose de connaitre toutes les failles de sécurité, comment elle marchent, ce que va taper le méchant ...

Une logique plus prudente est 'on ne laisse rien passer sauf ...' ; les points de suspensions étant a remplacer par les caractères alphanumérique, et quelques caractères de ponctuations triés sur le volet.

Et si le visiteur veut envoyer un lien ? Si sur le site, il y a un plantage et, gentillement (par exemple un webmaster complaisant) veut envoyer le message d'erreur ?

Si on le bloque à cause des caractères spéciaux, il ne va plus revenir sur le site.

Dans la sécurité, comme dans beaucoup de domaines, il faut trouver le juste milieu et se mettre, souvent, à la place de l'internaute, quand on développe.

Ca me fait penser à certains sites, qui refusaient sans aucune explication, certaines de mes adresses mels, car ils ne voulaient que des caractères alphanumériques dans le nom de domaine. Et les "-" et les "_", dommage

[_seb]

Tout à fait, il faut réfléchir un peu et autoriser des caractères permettant aux utilisateurs de saisir ce qu'il veulent entrer. Tu as raison de dire que l'utilisateur peut se sentir frustrer, il faut donc penser a ce qu'il vont saisir, comme tu as commencé a le faire.

Pour l'exemple des sites qui n'acceptent pas les mails avec des tirets, ils ont été vraiment mal pensés. Ce n'est pas un problème de sécurité, c'est de la betise.

Si on veut laisser passer les addresses web, on ajoute la regex qu'il faut, on transfome les url en liens cliquables, etc... On autorise ce qu'on juge bon de laisser passer, ça me parait plus sur

donc cette logique du 'autoriser rien sauf ...' me parait la plus prudente, c'est celle que j'adopte.

[Remi]

donc cette logique du 'autoriser rien sauf ...' me parait la plus prudente, c'est celle que j'adopte.

Comme tu as l'air de bien connaître le sujet, pourrais-tu développer quelque peu ?

Je suis assez curieux de voir comment par exemple tu utilises les regex pour autoriser et non pour détecter/interdire.

[_seb]

non, je ne suis pas un as de la regex, loin de là.

l'operateur ^ permet de dire 'qui n'est pas' par exemple

$chaine = preg_replace('![^a-z0-9 ]!i','',$chaine);

transforme tout ce qui n'est pas une lettre, un chiffre ou un espace en '' (rien).

Biensur, il faut quelque chose de plus large ne serait-ce que pour autoriser les tirets, underscore ...

La fonction strip_tags() de php marche avec ce même principe, on autorise aucune balise sauf ...

Modifié 22 Mars 2007 par _seb

[Leonick]

oui, ça on connait. Ce sont les bases des regex.

Mais comment appliques-tu cette règle de façon vraiment opérationnelle pour filtrer les contenus de formulaires ?

C'est ça qui nous intéresse

[froidure_nicolas]

Personnellement, j'ai une méthode moins prise de tête...

J'ajoute un content-type:text/html

Et je convertis tous les retours chariot du corps du message en br

( (\r?\n) => [br]).

Edit : Cependant, il me semble que ce problème est résolu dans les dernières versions de PHP.

Modifié 22 Mars 2007 par froidure_nicolas

[_seb]

[cite]Mais comment appliques-tu cette règle de façon vraiment opérationnelle[/cite]

euh...

et bien je filtre le contenu pour ce qui vient en titre et expéditeur comme précédement et pour le contenu du message, il n'y a pas de risque (je filtrez sevère avant mais je me contente de supprimer le html (striptags), je me sers de ces valeurs pour envoyer un mail... enfin je sais pas quoi expliquer de plus ...

au dela du pratique, je voulais surtout intervenir en terme de logique.

[Leonick]

je pense que c'est automatisé, dans une fonction ?

Ca serait intéressant pour nous d'avoir cette fonction.

Parce que la théorie c'est bien, on conceptualise notre sécurité, mais sorti des concepts, l'application réelle est largement moins évidente : à ne vouloir autoriser "que" ça risque de gêner l'internaute.