Complètement largué ! addslashes/ htmlentities - S.O.S

WRInaute accro
Bonjour,

Je commence réellement à me mélanger les pinceaux !!!!!
Pouvez-vous m'aider SVP !

à l'arriver de données de formulaires je fais cela:
Code:
$valeur_ok = trim(htmlentities(addslashes($_POST['valeur'])));

Pour l'afficher il me suffit d'utiliser la fonction: stripslashes()

Si je dois enregsitrer les informations dans la base de données j'enregistre directement ma variable $valeur_ok. Pour faire les comparaisons je dois donc comparer $valeur_ok avec trim(htmlentities(addslashes($_POST['autre']))).

J'ai donc dans ma base des anti-slash des é etc...

est-ce que je m'y prend bien ?
j'ai vraiment besoin de votre aide !!!!!!!
:cry: :cry: :cry: :twisted: :cry: :cry: :cry:

Merci
 
WRInaute occasionnel
Quand tu récupères des données d'une requête sql ou d'un formulaire ($_POST, $_GET), pour les afficher dans la page il faut faire : htmlentities(stripslashes()) : comme ça tu vires les éventuels caractères spéciaux et les quotes issus de la requête ou du passage de paramètre.

Pour insérer des données dans une base sans les bouziller avec des eacute il faut faire mysql_real_escape_string(stripslashes()).
Tu peux vérifier ça dans la doc
 
WRInaute accro
et pour faire des comparaisons entre des valeurs récupérée d'un formulaire et des données de la base de données...
 
WRInaute accro
en fait j'ai trop de mal toutes ces fonctions c'est bien pour protéger des attaques éventuelles, par exemple lors d'inclusion dans une base de données ne pas faire planter le système !?
 
WRInaute occasionnel
thierry8 a dit:
J'ai donc dans ma base des anti-slash des é etc...
htmlentities() n'aurait du servir que pour l'affichage dans le navigateur et non avant d'insérer. Il faudrait commencer par nettoyer ta base en faisant une moulinette qui applique html_entity_decode à tous les champs qui contiennent des eacute.

thierry8 a dit:
et pour faire des comparaisons entre des valeurs récupérée d'un formulaire et des données de la base de données...
stripslashes($_GET["toto"]) == stripslashes($row->toto)
ou alors
"select img where code ='". mysql_real_escape_string(stripslashes($_GET["toto"])) ."'";

thierry8 a dit:
en fait j'ai trop de mal toutes ces fonctions c'est bien pour protéger des attaques éventuelles, par exemple lors d'inclusion dans une base de données ne pas faire planter le système !?

En effet, ce sont des fonctions que php fournit pour protéger soit la base de données soit l'affichage dans le navigateur. C'est un peu lourdingue à utiliser mais c'est bien de les avoir. Ce n'est pas toujours le cas dans tous les langages !

Je te conseille de jeter un coup d'oeil à
http://www.php.net/manual/fr/function.stripslashes.php
http://www.php.net/manual/fr/function.addslashes.php

et aussi
http://www.php.net/manual/fr/function.m ... string.php
 
WRInaute accro
oui mais le htmlentities + addslashes permet de protéger des caractères % _ " ' # non ??? merci en tout cas pour ton aide ! mais j'ai vraiment du mal! !
 
WRInaute occasionnel
addslashes() sert à protéger des données avant de les passer en paramètre ($_GET) ou de les poster dans un formulaire ($_POST). Mais quand magic_quotes est activé dans la config de php, c'est fait automatiquement pour nous.
De plus il ne faut pas utiliser addslashes() pour protéger des données avant de les utiliser dans une requête sql destinée à la base mais plutôt mysql_real_escape_string.
Donc il n'y a jamais besoin d'utiliser addslashes().

stripslashes sert à "déprotéger" les données après les avoir récupérées d'un $_POST ou d'un $_GET pour les utiliser.

Par conséquent, quand on récupère un paramètre pour l'utiliser dans une requête sql, il faut dé-protéger les données par stripslashes puis le re-protéger pour mysql :
Code:
"select img where code ='". mysql_real_escape_string(stripslashes($_GET["param"])) ."'";

htmlentities() ne sert qu'au moment d'afficher des données dans le navigateur :
Code:
<?php echo htmlentities($message) ?>
Et encore pas toujours (affichage de texte via javascript).
 
WRInaute accro
Oula !
Ce n'est pas l'inversion pour les fonctions addslashes et stripslashes ?

Lorque l'on reçoit une données d'un formulaire on fait addslashes pour éviter les caractères spéciaux...

Quand on envoit on applique stripslashes pour un afifchage correcte ! Sinon on a le \' ?

exemple: (en ignorant la fonction automatique de php)
Code:
// je receptionne ma valeur en la protégeant.
$reception = addslashes($_GET['valeur']);

// je traite ma variable enregistrement par exemple dans la base de données.. (en ignorant l'autre fonciton, car celle-ci combinnées avec htmlentities offre une sécurité accrue [ce que j'ai pu en lire])

// je veux afifcher ma valeur
echo stripslashes($reception); affichage correcte des " '

Voila comment je résonne...???!

Encore une question lorsque l'on fait htmlentities('"',ENT_QUOTES) il n'est plus utile d'utiliser addslashes ?

Merci beaucoup de ton aide, j'espère ne pas te donner trop de mal !
:?
 
WRInaute accro
encore un truc, lors d'un formulaire pour envoyé un mail simple sans html !

Comment faire ?
Car l'utilisation de htmlentities provoque l'affichage de &amp,etc... mais si l'on ne s'en sert pas il peut y avoir des failles de sécurité non ?
 
WRInaute accro
J'ai bien tout relus ! A force ça rentre !
Par contre la fonction mysql_real_escape_string() ajoute donc des \, lorsqu'on récupère la valeur de la base de données, faut-il faire un stripslashes ?

Est-ce que cette fonction à elle seul permet de ne pas avoir d'erreur ?
(ou plutôt de ne pas avoir de faille dans la récupération de données et leurs gestion ?)

On peut donc lors de la réception (mis à par appliqué la fonciton stripslashes à cause de la conf. php.ini) utiliser la variable directement pour faire des comparaisons,etc...
Les deux seuls précautions à prendre sont lors de l'utilisation de la base de données ( donc utiliser mysql_real_escape_string() ) ET lors de l'affichage donc htmlentities().

N'y a t-il pas d'autre faille possible ou protection ?
Personnellement, travail tu de cet façon sur tes scripts pour la protection des données entrantes et sortantes ?

Par contre comme je le disais avant, pour les mails simple, par exemple pour le contenu principale, on ne peut appliquer de protection du style htmlentities, sinon la messagerie aura des &amp c'est bien ça ?

j'espère avoir bien compris !
UN GRAND MERCI POUR TOUTE TON AIDE !!!
encore un petit coup de pouce pour rassurer ma personne.. ;)
 
WRInaute occasionnel
thierry8 a dit:
J'ai bien tout relus ! A force ça rentre !
Par contre la fonction mysql_real_escape_string() ajoute donc des \, lorsqu'on récupère la valeur de la base de données, faut-il faire un stripslashes ?
Je pense que ça dépend de la config du système. sur mon hébergement, je crois qu'il n'est pas nécessaire de faire un stripslashes. Mais ce ne peut pas faire de mal d'en faire un (sauf si ta chaîne d'origine contient des \' mais c'est improbable)

thierry8 a dit:
Est-ce que cette fonction à elle seul permet de ne pas avoir d'erreur ?
(ou plutôt de ne pas avoir de faille dans la récupération de données et leurs gestion ?)
D'après la doc oui

thierry8 a dit:
On peut donc lors de la réception (mis à par appliqué la fonciton stripslashes à cause de la conf. php.ini) utiliser la variable directement pour faire des comparaisons,etc...
Oui par ce qu'elle n'a pas été abimée par des eacute

thierry8 a dit:
Les deux seuls précautions à prendre sont lors de l'utilisation de la base de données ( donc utiliser mysql_real_escape_string() ) ET lors de l'affichage donc htmlentities().
N'y a t-il pas d'autre faille possible ou protection ?
Personnellement, travail tu de cet façon sur tes scripts pour la protection des données entrantes et sortantes ?
Oui tout à fait, j'utilise ça. Je ne suis pas assez expert pour les autres failles. Une chose est sûr, mysql_real_escape_string permet d'éviter les injections sql et htmlentities (et nl2br) d'avoir un affichage correct


thierry8 a dit:
Par contre comme je le disais avant, pour les mails simple, par exemple pour le contenu principale, on ne peut appliquer de protection du style htmlentities, sinon la messagerie aura des &amp c'est bien ça ?
Pour les mails brut, en effet il ne faut rien protéger. Pour les mails html, il faut faire comme pour le navigateur.

thierry8 a dit:
j'espère avoir bien compris !
UN GRAND MERCI POUR TOUTE TON AIDE !!!
encore un petit coup de pouce pour rassurer ma personne.. ;)

De rien. Avec plaisir
 
WRInaute accro
Wouahh !!! ça veux dire que j'ai compris !!!!!!! fiouuuuu
Je croyais ne jamais m'en sortir !

Par contre j'ai tester, mais il me reste un petit soucis !
Ma base de données et en utf-8 ! Et le problème est que la fonction mysql_real_escape_string() apparement ne le prend pas en compte...
Comment puis-je faire ?
 
WRInaute accro
Je crois que je vais laisser ma base en utf-8 et l'affichage des données en ISO....15 !

Une question encore, après avoir injecté des valeur dans la base de données, si je les récupère de la base de données ensuite faut-il appliquer le htmlentities ?

car lorsque je le fais il m'affiche #168...etc, enfin ca dépend du caractère en question ? applique tu la fonction après récupération de données de ta base ?
ou uniquement lorsque tu affiche directement la valeur d'un post ou get ?
 
Discussions similaires
Haut