djangoboy
Messages postés54Date d'inscriptionlundi 14 avril 2003StatutMembreDernière intervention25 septembre 2007
-
2 nov. 2005 à 08:37
psychosic
Messages postés46Date d'inscriptionlundi 24 janvier 2005StatutMembreDernière intervention11 novembre 2005
-
14 nov. 2005 à 12:26
Bonjour a tous,
Il y a 3 jours précisement je me suis fais tapé sur les doigts par monoceros01 et anthomicro car j'ai employé les fonction suivant pour traiter mes formulaires.(Mais heuseusement qu'ils l'ont fait !)
J'utilisé :
que ca soit pour les input text ou les text array.
J'aimerais donc savoir "les normes", qu'est ce que je dois mettre pour être sur que les caractère déchapemment soit mis correctement, pour pouvoir enregistrer ces informations dans ma base de donnée, pour ensuite les publier sur mon site sous formes de news.
Donc si quelqu'un aurait la gentillesse de m'aider, car j'ai réfléchi aux lignes de code apparaissant plus haut, c'est vrai que certain serveur sont configuré autrement.
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 2 nov. 2005 à 09:00
Hello,
- les quotes... : le truc est de savoir comment ton serveur est configuré. Gère t il tout seul les quotes avec les magic quotes ? Mais ne se baser que sur ça pose un problème de portabilité (et si tu changes de serveur, et que la gestion des quotes change...tu ne voudrais pas devoir revoir tout ton code ;-)). Le mieux est donc d'utiliser un script comme celui d'Antho : http://www.phpcs.com/code.aspx?id=29887 Ps : ceci se gère AVANT tout enregistrement dans une base, passage de variable par get ou post, etc...
PHP possède une fonction propre à mysql pour gérer ça : mysql_real_escape_string () que je préconise d'utiliser dans ces cas-là. Prendre cette précaution va déjà bloquer la plupart des éventuelles attaques injections sql.
A lire :
http://fr.php.net/magic_quotes//code.aspx?id=29887/code.aspx?id=29887
- htmlentities : les entités html peuvent être pénibles pour la mise en page d'un site. Un exemple typique : forum, livre d'or...si le mec s'amuse à mettre un
(ou un </table> vu que généralement les gens font -malheureusement- de la mise en page par tableaux...), ça peut mettre à mal un design concocté avec amour. Il y a plus ennuyeux : le javascript. Je ne vais pas donner ici un exemple de petit script nuisible, mais bon...c'est pas très dur à trouver ;-) . C'est pour ça que généralement, sur toute entrée utilisateur, on utilise htmlentities (ou html_special_chars quand on gère bien l'encodage de ses pages).
A lire : http://fr2.php.net/htmlentities
- nl2br : ça, c'est juste une question de mise en page. Ca remplace les retours chariots "systèmes" par de bons vieux
. Ca permet de garder la "mise en page" (les retours chariots uniquement en fait) de l'utilisateur lors d'une saisie dans un textarea par exemple. Aucun soucis de sécurité ici.
- ucfirst : heu bah ça c'est cosmétique, encore une fois. ca met des majuscules...il y a deux fonctions pour ça. Aucun problème de sécurité là-dedans.
Pour la pratique de recopier la valeur d'une globale (un $_POST par exemple) dans une tierce variable...si tout est bien géré, je n'en vois pas l'utilité.
Dans tous les cas, ce qui est important : ne jamais faire confiance à l'utilisateur. Toujours bien vérifier que l'on reçoit ce que l'on attend, et pas autre chose! Toujours vérifier l'existence des variables (attendues) lors d'une saisie utilisateur (avec des isset () : http://fr2.php.net/isset). Toujours vérifier leur contenu (tu attends un entier dans une saisie ? Vérifie que ça en soit un! Le cas échéant, force la conversion de la saisie). Et toujours gérer les cas d'erreur...si tu n'as pas la valeur voulue, déclenche une erreur toi-même, n'attend pas que php le fasse et affiche son vilain message aux yeux de tous. Ca peut, dans certains cas, aiguiller des gens mal intentionnés. Et puis ça ne fait pas pro ;-) Travaille toujours en error_reporting à E_ALL, c'est important pour sécuriser au mieux un site : http://fr.php.net/error_reporting.
Il y aurait des tas de choses à dire...je laisse le soin à d'autres de faire des ajouts.
FhX
Messages postés2350Date d'inscriptionmercredi 13 octobre 2004StatutMembreDernière intervention18 avril 20153 2 nov. 2005 à 11:07
"PHP possède une fonction propre à mysql pour gérer ça :
mysql_real_escape_string () que je préconise d'utiliser dans ces
cas-là. Prendre cette précaution va déjà bloquer la totalité des attaques type injections sql."
"Dans tous les cas, ce qui est important : être parano à 150% !."
malalam
Messages postés10839Date d'inscriptionlundi 24 février 2003StatutMembreDernière intervention 2 mars 201025 9 nov. 2005 à 09:08
Le problème de base64 est qu'elle allonge sérieusement les chaînes,
donc pour traiter ces cas-là, autant utiliser les fonctions dédiées, à
mon sens.
J'utilise base64 essentiellement quand je veux trimballer dans une
variable, ou dans un champ caché, un objet/tableau sérialisé. Ca vire
les caractères à la con ;-)