Discussion :

[Lost In Translation]

Coucou,

Une petite question me passait par là.

J'ai l'habitude de protéger mes champs par htmlspecialchars() et real_escape_string() sur des input de type texte (et textarea) vu que les données sont saisies par des utilisateurs.

Faut-il aussi faire de même pour les input de type radio,checkbox et select ?
En gros, est-il possible qu'un utilisateur puisse "par je sais quel moyen" transformer le champ de notre formulaire en un autre champ et saisir "ce qu'il veut" ?...

Parce que bon, imaginons, je protége le nom et le prénom.
Le troisième champs est une liste (select) d'âges allant de 11 à 121 ans...

Par un prodige que je ne connais pas "peut être un logiciel qui se surcouche au navigateur", le mec change "à la volée le formulaire", m'en fait un champ de saisie... et au lieu de m'envoyer un simple entier (que je ne testerais pas, naif que je suis étant persuadé que via une liste on ne peut rien m'envoyer de néfaste) m'envoie un truc pas sympa.

En gros dans mon délire paranoïaque :
- faut il tester tout ce qui est envoyé par POST, même les champs select, radio, checkbox et hidden ?

- peut-on substituer le type d'un champ et envoyer ça au serveur "naturellement" ? Si oui... est-ce que l'inventeur de ça est en prison :p ?

Merci ^^

[FoxLeRenard]

Coucou,

Une petite question me passait par là.

J'ai l'habitude de protéger mes champs par htmlspecialchars() et real_escape_string() sur des input de type texte (et textarea) vu que les données sont saisies par des utilisateurs.

Faut-il aussi faire de même pour les input de type radio,checkbox et select ?
En gros, est-il possible qu'un utilisateur puisse "par je sais quel moyen" transformer le champ de notre formulaire en un autre champ et saisir "ce qu'il veut" ?...

Parce que bon, imaginons, je protége le nom et le prénom.
Le troisième champs est une liste (select) d'âges allant de 11 à 121 ans...

Par un prodige que je ne connais pas "peut être un logiciel qui se surcouche au navigateur", le mec change "à la volée le formulaire", m'en fait un champ de saisie... et au lieu de m'envoyer un simple entier (que je ne testerais pas, naif que je suis étant persuadé que via une liste on ne peut rien m'envoyer de néfaste) m'envoie un truc pas sympa.

En gros dans mon délire paranoïaque :
- faut il tester tout ce qui est envoyé par POST, même les champs select, radio, checkbox et hidden ?

- peut-on substituer le type d'un champ et envoyer ça au serveur "naturellement" ? Si oui... est-ce que l'inventeur de ça est en prison :p ?
Merci ^^

Indiscutablemnt la réponse est OUI !!

Mais il faudrait ouvrir le débat sur la sécurité, et je crois avoir lu que nos "Rédacteurs" préparent un TOPO sur le sujet,

Je ne veux donc pas trop m'étendre ici.

Cependant je dirais plus on interesse de monde , (par exemple le site WEB de l'AFP) plus les grosses pointure en matiére de Hackage vont tenter leur chance.

Plus on est modeste, moins on intéresse les Hackers (les vrais) pas plus de 2000 dans le monde !

Reste donc pour nos sites WEB a nous protéger des "bricoleurs" et ça
c' est plus facile.

Quand tes formulaires sont des POST rien n' apparait dans la bare d' adresse.
Par contre si tes formulaires sont en GET dans la barre d' adresse, tu as toutes les infos, même les hidden

Admetons que j'ais un FORM avec un seul chanp SELECT par exemple
dont le nom soir langue

J'aurais bien dans la barre d'adresse

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
http://www.monsit.com/xxx.php?langue=france

Tu vois que je peux me faire sur mon micro un mini HTML qui aurait ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
<a href="http://www.monsit.com/xxx.php?langue=0xh28Ck12<exjava>for httpdeal">et voila </a>

Ors sache que le POST est mieux protégé, mais pas tant que cela

[trotters213]

Quelques bonnes pratiques :

• Tester la valeur de chaque champ du POST afin qu'elle matche les valeurs que tu attends.
• Ne jamais utiliser la fonction extract.
• Pour ce qui est des accès BD, il est préférable d'utiliser une solution d'abstraction de BD

En gros, il faut te dire que TOUT peut être hacké et partir de ce principe là (et pas l'inverse en te disant que tout est sécurisé sauf telle ou telle fonction )

[Lost In Translation]

Alors non ça ne sera pas le site de l'AFP. C'est un jeu. Et qui dit jeu, dit "je veux être le meilleur" et dans ce cas là, certains sont prêts à vendre père et mère.

Alors en général je teste les champs mais c'est vrai que j'ai pas l'habitude de tester les champs où l'on ne saisit pas manuellement. Maintenant, c'est vrai que c'n'est pas non plus "plus long".

J'utilise rarement $_GET dans un formulaire... mais je l'utilise, donc en général j'ai tendance à protéger, mais peut être pas assez.

J'vais repasser dans mon code pour voir si j'ai rien oublié.

* Tester la valeur de chaque champ du POST afin qu'elle matche les valeurs que tu attends.
* Ne jamais utiliser la fonction extract.
* Pour ce qui est des accès BD, il est préférable d'utiliser une solution d'abstraction de BD

Alors pour le point 1, promis j'vais finir de le faire ^^
Pour le point 2, je ne l'utilise jamais
Pour le point 3, MySQLi - que j'adore - me semble au poil pour ça

... euh, du coup, il faut aussi protéger ce qui est mis en session ?
Nan parce que bon, imaginons que je mette :
$_SESSION['var_de_mon_choix_qui_vient_de_mon_imagination'] = 'toto';...
Y a moyen que Pinguins vienne et me la modifie en 'tata' ? Parce que dans c'cas là, faudrait que je fasse aussi gaffe quand je récupère les valeurs de ma session d'une page à une autre...

Alors, alors ?

Merci

[FoxLeRenard]

... euh, du coup, il faut aussi protéger ce qui est mis en session ?
Nan parce que bon, imaginons que je mette :
$_SESSION['var_de_mon_choix_qui_vient_de_mon_imagination'] = 'toto';...
Y a moyen que Pinguins vienne et me la modifie en 'tata' ? Parce que dans c'cas là, faudrait que je fasse aussi gaffe quand je récupère les valeurs de ma session d'une page à une autre...
Alors, alors ?

Décidément dur dur de continuer sans faire le tour de la question sécuritée
En tout cas tu fais comme tu veux, et je te réponds clairement sur cette derniére question,

LORSQU'UN VISITEUR SE DELOGUE OU EST INACTIF PLUS DE XXX secondes

1) ON NE PEUT SUPRIMER UN COOKIES mais on peut réécrire dedans, donc remets en écriture des valeurs bidons ,pour tes valeurs "sensibles"
2) Vide sa session !!

Voici les précautions élémentaires a respecter sur ce point,

Pour le reste je te conseilles , faisant un site de jeux, de lire l'exellent livre
Securité PHP5 et MYSQL chez Eyrolles

[Lost In Translation]

Pour le delog, j'ai pas de soucis. J'explose la session...

Mais est-ce que lui il peut modifier les données de sa session à la volée ?
Parce que si c'est oui... dans c'cas là, effectivement, j'ai tout intérêt à éviter qu'il foute des caractères à la con (car à part une faille XSS je vois pas) pour foutre le bordel.

[FoxLeRenard]

Pour le delog, j'ai pas de soucis. J'explose la session...

Mais est-ce que lui il peut modifier les données de sa session à la volée ?

T' explose ça c' est parfait 100%
Pour le reste c'est NON sois tranquille !! mais attention, c'est toi qui remplis
les valeurs de session, alors si une des valeur viens d'un GET ou d'un POST, on en a parlé donc TOUT EST OK

[Lost In Translation]

Oki Doki.

Merci Fox et Trotters pour l'échange et vos réponses.

J'ai des trucs à corriger du coup mais c'est positif en tout cas.