Sécurisation formulaire

[OJAL]

Bonjour,

Soit un formulaire classique utilisant la méthode post.
J'effectue une validation du contenu des champs dans le script contenant le formulaire.
Ceci me fait penser que les données transmise dans le script de traitement du formulaire seront donc conformes à ce que j'attends...

Est-ce exact? Un mal attentionné peut-il injecter des paramètres directement dans le script de traitement :?:
Si oui, comment celà se réalise-t-il :?:
Il faut alors aussi vérifier le contenu des champs dans le script de traitement :?:

Merci par avance ;-)

 

[UsagiYojimbo]

Il suffit de filtrer les données et de vérifier que pour chacun des champs, ce que tu obtiens correspond à ce que tu attends (vérification côté serveur j'entends, donc en php).

 

[Selection A]

Soit un formulaire classique utilisant la méthode post

Déjà avec une addon firefox il est tres facile de modifier la méthode de POST à GET !

Je confime : parser côté serveur les données recues afin de contrôler leur validité me semble sufisant

 

[OJAL]

Oula, en effet, je viens d'installer TAMPER DATA et à priori ça permet d'injecter tout ce qu'on veut ce truc la... brrrr... Ca fait froid dans le dos

Il FAUT donc bien tout revérifier coté serveur en effet ;-)

Merci.

 

[Leonick]

sauf que pour spammer un formulaire, on n'a pas besoin d'un navigateur. curl suffit à le faire

 

[OJAL]

OK pour CURL en effet, avec toute la puissance d'une bonne programmation derrière...
Alors que les extensions FF sont plus accessibles à tout le monde...

Et bien, je commence à comprendre pourquoi il y a tant d'attaques de formulaires ;-) Je n'étais jamais rentré dans ce sujet...

Vous avez des liens synthétisant bien les précautions à prendre :?:
Je pourrais en trouver sur GG, mais vos liens seront certainement plus intéressants ;-)

 

[xTrade]

Il FAUT donc bien tout revérifier coté serveur en effet ;-)

A partir du moment où on peut voir les paramètres que tu passes, il est plus que logique qu'une vérification coté serveur soit implantée.
Je fais une double vérification : par javascript pour que l'utilisateur "normal" puisse voir tout de suite ses erreurs et validation coté serveur.
Cela double le travail, mais il n'y a pas le choix

 

[OJAL]

C'est ce que je vais m'atteler à faire...

Merci ;-)

 

[Leonick]

OK pour CURL en effet, avec toute la puissance d'une bonne programmation derrière...
Alors que les extensions FF sont plus accessibles à tout le monde...

oui, mais pour spam de base, mais pas le spam de masse.
Par exemple, tu installes les principaux scripts d'annuaires et de forum, tu regardes quelles sont les variables utilisées, tu crées ton script curl pour envoyer un formulaire puis, soit tu testes l'url sur tous les sites, soit tu recherches, par exemple, un annuaire recensant tous les freeglobe, categorizer, etc... et tu attaques avec les scripts correspondant.
Même en faisant de l'url rewriting, l'url classique continue d'être accessible.
C'est pour cela que, finalement, j'ai développé mes propres solutions d'annuaires avec un certain nombre de vérification/nettoyage des informations entrantes

 

[OJAL]

Il serait intéressant de bien recenser les chaines de caractères qui ne doivent pas être injectées de façon à s'en débarrasser... J'imagine que plein de WRIstes se sont déjà fait leurs propres filtres :?: Et ont des retours sur leurs efficacité...

 

[Bacteries]

PHP possède déjà plein de fonction pour ça
intval
strip_tags
htmlspecialchars
PDO permet d'avoir des requêtes préparées
, ...

 

[zeb]

J'imagine que plein de WRIstes se sont déjà fait leurs propres filtres :?: Et ont des retours sur leurs efficacité...

stripslashes() et htmlentities() permettent de pas mal limiter la casse face aux injection HTML et SQL dans la mesure ou les caractères spéciaux comme les simple Quote (et les doubles) sont stérilisés. (les <> aussi qui sont bien utiles pour violer un formulaire d'accès)

Un autre truc qui limite un peut mais qui n'évite pas le mec déterminé a passer est de passer l'id de session dans un input hidden afin de le comparer avec celui que tu as sur le script de traitement. une différence entre les deux est un indicateur de bot mal foutu.

les questions type captcha sont souvent utiles aussi.

Tant qu'a penser formulaire, méfie toi aussi de tes scripts ajax ;-)

 

[Leonick]

Il serait intéressant de bien recenser les chaines de caractères qui ne doivent pas être injectées de façon à s'en débarrasser...

en fait, pour bien sécuriser il faut procéder à l'envers : se demander ce que l'on doit avoir et n'autoriser que cela.
Si une variable doit être numérique, on le vérifie. Si ce n'est pas le cas, on rejette le contenu. Et si on le réaffiche, il faut faire attention à ce qu'on réaffiche pour pas qu'il n'y ait, là encore, une tentative d'injection XSS