Problème lors de "sécurisation" des variables.

[Thoomas]

Bonjour,

J'ai intégré sur mon site (en local toujours) un formulaire d'envoi (avec possibilité d'intégrer du html/css), de ce fait pour éviter tout type d'injection j'applique à mes variables afin d'éviter tout les types d'injection :

mysql_real_escape_string(stripslashes(htmlspecialchars(trim($chaine))))

Mais après, quand je reçois sur ma zone admin et que j'affiche, c'est un véritable bordel (normal vous me direz) : des slashs partout, des balises html mises en &...; etc, etc !

Il y a t'il une solution pour recevoir "normalement" sur ma zone admin ? Une solution serait de virer la sécurité mais ça ouvrirait aux attaques hack...

J'attends vos avis / propositions !
Merci,

 

[Julia41]

Si tu affiches avec htmlspecialchars c'est normal car c'est déjà échappé.
Tu devrais utiliser la fonction striptags plutôt pour les script malicieux.
Les vrais variables à filtrer son connues.
Si tu es en php5, tu devrais utiliser la fonction filter de php. Elle permet de nettoyer les trucs "sensibles" dans un premier temps.
Après à toi d'ajuster ce que tu souhaites réellement permettre à l'utilisateur au final.

Au niveau de ta requête SQL, je placerais le trim en premier.

 

[Thoomas]

C'est assez compliqué pour moi de tout piger (je débute encore ) !

Qu'est ce que tu me conseilles (à part changer l'ordre) qui ne casserait pas tout le code du visiteur ?

Merci !

 

[Julia41]

Bah si tu strip tags, ça vire toutes les balises html. Après tu peux en autoriser:

strip_tags($text, '<strong><em>');

tu peux entrer des caractères "méchants" dans ta base de données ce n'est pas "trop" gênant.
Par contre, à l'affichage :

htmlspecialchars($ton_text);

Si c'est pour un forum, faudra faire un mix de nl2br.

Le mieux est de tester avec des phrases toutes faites "sensibles" comme :

L'amour c'est génial

Tu as quelques trucs qui permettent de voir rapidement si les apostrophes sont bien échappé et le charset avec le "é" de génial.
Pareil pour des codes de XSS pour voir si ça passe ou non.

 

[Thoomas]

Mais ce que je ne comprend pas c'est que c'est bien de bloquer tags etc (pour sécuriser) mais après si on veut afficher ce qui vient du formulaire sur une page... le texte sera détruit.

Comment faire pour sécuriser les envois mais afficher le texte après normalement ? Car là, si je fais ce que tu dis, quand j'afficherais les balises seront en < ...

Si je ne mets que mysql_real_escape_string pour l'envoi de données via un formulaire (qui sera stocké dans la base de données), ce n'est pas suffisant ?

 

[tryan]

Tu fais simplement :

 mysql_real_escape_string(stripslashes($chaine));

Et comme visiblement tu vérifies depuis ton admin., tu ajoutes ajoute un "trim()" avant validation pour virer les espaces.

Comme Julia41te le propose, tu ajoutes éventuellement un "trip_tags".

 

[Thoomas]

Le simple fait de mettre mysql_real_escape_string(stripslashes($chaine)); évite les failles SQL ?

Car on enlève immédiatement les slashes ajoutés avec mysql_real_escape_string... stripslashes "annule pas l'effet" de mysql_real.. ?

 

[Julia41]

mysql_real_escape_string sécurise ce qui rentre dans mysql.
Tout ce qui est SELECT / INSERT / UPDATE doit être passé par du mysql_real_escape_string.
Cette fonction gère parfaitement ce que tu mets dedans.
Si tu mets des apostrophes, ça fonctionnera, et si tu mets un stripslashes, il rajoutera des slashes pour l'insertion.
ta requête :

INSERT INTO post (text) VALUES ('l\'amour c\'est génial');

Si tu fais un strip_slashes devient

INSERT INTO post (text) VALUES ('l'amour c'est génial');

Mais mysql_real_escape_string se charge d'en rajouter pour l'insertion.

En tout cas, oui, ça "évite" les failles SQL de mettre du mysql_real_escape_string en nettoyant le code pour l'inserer/mettre à jour correctement.

 

[Thoomas]

Eh bien merci à vous deux, le problème est donc résolu !

C'est gentil d'avoir expliqué le mysql_real... merci beaucoup !