Aller au contenu

Probleme d'insertion antislash dans mysql


sandrinoo

Sujets conseillés

Bonjour,



des fois, on en a marre de tourner en rond toute seule avec son pb, qu'on a testé, retesté, retesté encore, on perd courage alors on se tourne vers la communauté.



J'utilise la fonction mysqli_real_escape_string pour générer des antislashes devant des apostrophes.



- Quand je fais un echo de la variable sur la page php, l'antislash s'affiche correctement.


Mais lors de l'insertion Mysql, les antislashes devant les apostrophes n'apparaissent pas.



- C'est exactement la même chose si j'utilise addslashes (à la place de mysqli_real_escape_string).



- Par contre si j'utilise mysqli_real_escape_string+addslashes alors là j'ai en echo php 3 antislashes et en BD 1 antislash.



Bizarre non ?




Je précise que :


- j'ai bien désactivé les magic quotes via le fichier htaccess (sur OFF dans phpinfo)


- ma BD est en utf8_general


- ma version php est 5.2.17



Si quelqu'un a déjà été confronté au problème, ça serait sympa pour le coup de main...



sandy


Lien vers le commentaire
Partager sur d’autres sites

Est-ce que le jeu de caractères par défaut est bien défini sur le serveur, ou bien avec mysqli_set_charset() ?






Securité : Le jeu de caractères par défaut

Le jeu de caractères doit être défini soit au niveau serveur, soit avec la fonction API mysqli_set_charset() pour qu'il affecte la fonction mysqli_real_escape_string(). Voir la section sur les concepts on des jeux de caractères pour plus d'informations.



Lien vers le commentaire
Partager sur d’autres sites

Merci de m'avoir répondu Dan.



Je ne suis pas sûre d'avoir tout compris. J'ai intégré dans ma page php cela (en changeant juste $link bien sûr) :



/* Modification du jeu de résultats en utf8 */
if (!mysqli_set_charset($link, "utf8")) {
printf("Erreur lors du chargement du jeu de caractères utf8 : %s\n", mysqli_error($link));
} else {
printf("Jeu de caractères courant : %s\n", mysqli_character_set_name($link));
}

et en résultat sur ma page php j'ai "Jeu de caractères courant : utf8"


donc c'est bon non ?



Mais en Base de données toujours pas d'antislash avec mysqli_real_escape_string


Lien vers le commentaire
Partager sur d’autres sites

Bonjour,



Pourquoi veux-tu un antislash dans ta BDD? Quel intérêt?



Si l'insertion se passe bien, c'est que ta requête est bonne.



L'antislashes() sert justement à échapper les quotes pour que ta requête ne plante pas. Tu ne les verras pas dans ta table.




Portekoi


Lien vers le commentaire
Partager sur d’autres sites

Merci Portekoi de me répondre.



Je croyais qu'il fallait un antislash devant mes apostrophes en Base de données pour éviter de futures injections SQL malveillantes.



Ai-je tort Portekoi ?


Lien vers le commentaire
Partager sur d’autres sites

Bon, personne ne voit mon problème alors ):



Moi je pensais que



l'aiguille

devait s'enregistrer



l\'aiguille

dans ma base de données (après être passée par la fonction mysqli_real_escape_string).



Portekoi me dit que j'ai tort, c'est vrai ?



Quelqu'un peut au moins répondre à cela svp ?


Lien vers le commentaire
Partager sur d’autres sites

Les antislashes ajoutés sont utilisés pour éviter les injections SQL : si dans ta requête une des valeurs est délimitée par des apostrophes, ajouter une apostrophe sans l'échapper peut permettre d'effectuer une requête toute autre que celle prévue initialement, et ainsi dévoiler des données de ta base de données.



Pour remédier à cela, on échappe les caractères à risque (apostrophes et guillemets, entre autres) lors de la requête d'insertion, mais en aucun cas ces apostrophes ne sont censés être présents en base : tes données enregistrées n'ont pas à être échappées dans la base elle-même.


Lien vers le commentaire
Partager sur d’autres sites

En fait :



l'aiguille




va devenir le temps de la requête



l\'aiguille




Mais à l'arrivée dans la base, cela sera :



l'aiguille




L’antislash, c'est juste au moment de la requête. Donc pas besoin de le stocker.


Lien vers le commentaire
Partager sur d’autres sites

Ah, je commence à comprendre. Merci Portekoi.



1/ Mais alors si il y a une injection sql malveillante, elle va quand même se retrouver dans ma BD non ? Tu veux dire qu'elle est rendue inoffensive le temps de l'injection mais que ce code malveillant s'enregistre normalement dans ma bd sans antislash



2/ A quoi sert alors la fonction srtipslashes() : je croyais qu'elle servait supprimer les antislashes en affichant correctement sur ma page les données de ma base de données enregistrées avec un antislash ?



3/ Comment puis-je vérifier que système fonctionne correctement et que ma BD est bien protégée ?



Merci de bien vouloir me répondre une dernière fois Portekoi...


Lien vers le commentaire
Partager sur d’autres sites

1/ Une injection malveillante. Exemple :



select mdp from user where login = '$login' and mdp = '$mdp';



Si $login vaut :



' or 1=1; update user set mdp = 'a' --

Sans addslashes :



select mdp from user where login = '' or 1=1; update user set mdp = 'a' --' and mdp = '$mdp';

Renverra toutes les données de la table 'user'



2/ stripslashes() ne me sert pas. :


http://stackoverflow.com/questions/6399833/is-there-a-reason-why-i-need-to-use-stripslashes-for-user-submitted-data



3/ Perso, je pars du principe que même la NASA c'est fait piratée. Ton système ne sera jamais infaillible. Il faut essayer de faire au mieux. Tu peux par exemple filtrer des mots comme "DELETE" ou "UPDATE" dans tes variables.


Lien vers le commentaire
Partager sur d’autres sites

Merci beaucoup Portekoi.



En fait la fonction mysqli_real_escape_string(), d'après ce que j'ai compris, simplifie bien les choses.



Merci encore et bonne journée à toi.



sandy.


Lien vers le commentaire
Partager sur d’autres sites

  • 2 semaines plus tard...

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...