Mot "interdits" (cascade, reunion, trigger)

[Samuel MONTAGNE]

Bonjour.

 

J'ai un problème hallucinant : je n'arrive pas

à créer un produit contenant le mot 'cascade'

dans le champ 'Nom'.

 

Si j'enlève de 'E' de cascade, ça passe, si je

le remets, ça passe plus !!!!

 

Le message d'erreur est :

1. une erreur s'est produite pendant la mise à jour product

 

Suis je devenu fou ? (ma mère vous répondrez

sans doute oui d'office )

[DrÿSs']

Bonjour,

 

Oui cela est bug connu, qui malheureusement ne sera pas corrigé tout de suite.

Cela vient du fait que le mot cascade se trouve dans notre "black-list" de mots malveillants pour MySQL (comme reunion par exemple).

 

Nous réfléchissons pour contourner ce problème.

[Samuel MONTAGNE]

Peux ton supprimer ce mot de la black liste ?

 

Même juste le temps de créer l'article ?

[Samuel MONTAGNE]

J'ai trouvé : fichier Db.php, dossier classes ligne 49 !

[Philippe]

Après le mot Réunion, voici un autre mot qui pose problème : Trigger

 

Lorsqu'il fait partie du nom du produit, il devient impossible de valider la fiche produit dans le back-office.

 

Le message suivant apparait : "Une erreur s'est produite pendant la mise à jour de product".

 

[DrÿSs']

Pour info, voici la liste des mots interdits :

 

private static $_blacklist = 'UNION|LOAD_FILE|OUTFILE|DUMPFILE|ESCAPED|TERMINATED|CASCADE|INFILE|X509|TRIGGER|REVOKE';

 

Si vous êtes confronté à ce problème et que vous aimeriez vraiment utiliser un de ces mots, vous pouvez éditer le fichier classes/Db.php (l. 49).

 

(à vos risques et périls)

[businesswoman]

Pour info, voici la liste des mots interdits :

 

private static $_blacklist = 'UNION|LOAD_FILE|OUTFILE|DUMPFILE|ESCAPED|TERMINATED|CASCADE|INFILE|X509|TRIGGER|REVOKE';

 

Si vous êtes confronté à ce problème et que vous aimeriez vraiment utiliser un de ces mots, vous pouvez éditer le fichier classes/Db.php (l. 49).

 

(à vos risques et périls)

 

J'ai recherché le mot ' ; trigger' ; dans le thesaurus - voici quelques suggestions pour des mots alternatifs : nom Quelque chose qui incite particulièrement une réponse violente : aiguillon, incitation, incitation, instigation, provocation, stimulus. Voir la cause verbe Pour être la cause de : apportez, provoquez, apportez dessus, cause, effet, effectuez, produisez-vous, induisez, ingenerate, menez à, faites, occasionnez, résultez dedans, bloqué, placez au loin, le stir 1 (vers le haut), touchez au loin. Idiomes : apportez pour passer (ou effet), provoquez. Voir le début Pour remuer à l'action ou au sentiment : egg dessus, excitez, fomentez, galvanisez, aiguillonnez, poussez, incitez, enflammez, inspirez, incitez, motivez, déplacez-vous, piqué, piqûre, aiguillon, message de sollicitation, propulsez, provoquez, ensemble au loin, dent, stimulez, touchez au loin, travail vers le haut. Voir la cause, l'excitez

[soclass]

Et pourquoi une black list ? je ne comprends pas.

[DrÿSs']

Ce sont des mots dangereux pour les requêtes SQL, sécurité oblige.

[ladykyller]

Bonjour je viens d'avoir le même problème ce qui me cause un bug au niveau des produits sur le site, cela m'affiche qu'il y a un produit avec la quantité le tarif sans image et sans descriptif, impossible de le retrouver dans le panneau d'administration, que se soit en y rentrant la référence ou le nom du produit que puis-je faire?

Merci

[SotEW]

Pour le produit invisible, il me semble qu'il faut aller supprimer manuellement les produits 'vides' dans la base de donnée.

pour ce qui est des mots en black-list, la solution que j'ai trouvé pour les utiliser dans une DESCRIPTION sans les retirer du fichier DB.php, c'est de couper la séquence de caractères avec des balises html invisible ensuite (donc, en éditant la description en mode 'source html'):
exemple pour union :

union

voila, sans supprimer de mots en black-list => pas de faille de sécurité


je n'ai pas encore trouvé d'astuces pour les titres/nom de pays. Peut-être créer l'objet et ensuite modifier le nom dans la base de donnée ??

[Jean-Bruno]

Bonjour,
J'ai le fameux message

1 erreur 1. une erreur s'est produite pendant la création de l'objet

lors de la duplication d'un objet et je ne trouve aucun mot interdit (de plus le produit a déjà été déjà créé).
J'ai pensé au droit du dossier image mais ça ne marche pas mieux
Une idée ?

[Jean-Bruno]

Bonjour à tous
Toujours pas d'idée ?

[jdam]

Bonsoir
je voudrais répondre à SotEW et lui tirer mon chapeau. En effet, moi aussi j'ai été bloquer dans la création d'un nouveau pays, en l'occurence La Réunion, mais ça ne passait pas, j'ai essayé La Réu-nion comme un autre le préciser et ça passe mais un peu bizarre. Donc j'ai modifié le fichier Db.php selon SotEW avec 'UNION et ça marche nickel, bravo. Faillait trouver!!!!!! Quoi qu'en fouillant dans le forum on a toujours réponses à tout, mais faut suer un peu pour cela.
Bonne soirée

[Patric]

Bonsoir
je voudrais répondre à SotEW et lui tirer mon chapeau. En effet, moi aussi j'ai été bloquer dans la création d'un nouveau pays, en l'occurence La Réunion, mais ça ne passait pas, j'ai essayé La Réu-nion comme un autre le préciser et ça passe mais un peu bizarre. Donc j'ai modifié le fichier Db.php selon SotEW avec 'UNION et ça marche nickel, bravo. Faillait trouver!!!!!! Quoi qu'en fouillant dans le forum on a toujours réponses à tout, mais faut suer un peu pour cela.
Bonne soirée

Ce n'est pas du tout le conseil que donne SotEW. En faisant ce que tu as fait tu as créé un trou de sécurité car tu as modifié l'un des termes du fichier Db.php. C'est exactement comme si tu l'en avais supprimé...
Il faut donc remettre UNION tel qu'il était dans ce fichier.

SotEW ne recommande donc pas de modifier le fichier Db.php.
L'astuce de SotEW fonctionne uniquement si tu veux utiliser l'un des mots par exemple dans une description de produit.
Par contre j'ai bien peur que pour l'utiliser en tant que nom de pays, ça ne le fasse pas...

[jdam]

Ok Zendik
Je me disais aussi que je n'avais pas bien saisi l'astuce de SotEW. Ca ne change finalement rien de rectifier dans le Db.php, la faille est toujours là.
Donc pour nous à la Réunion pas de chance pour le e-commerce avec Prestashop. Il me reste donc 'La Réu-nion" ou ile-de-la-réu-nion", ca marche mais cela reste bizarre lors des inscriptions. Mais bon, c'est le seul petit problème que j'ai rencontré pour le moment avec Prestashop, qui m'a vraiment séduit pour un Open Source
Cordialement

[CMMC]

Il y a aussi les mots qui finissent par union comme communion (j'ai eu le cas en voulant mettre un metatag) qui génèrent un message d'erreur

[StoreCommander]

Par définition, aucun module ne doit modifier cette blacklist pour garantir la sécurité de la boutique. Par contre vous pouvez créer un second fichier Db.php que vous appelez DbRiskxxx.php avec une blacklist réduite et vous échangez les noms des fichiers par FTP avant de faire des modifications dans le backoffice puis lorsque vous avez terminé, vous ré-échanger les noms des fichiers (ne pas oublier !).
La boutique ne serait vulnérable que lors des quelques minutes pendant lesquelles vous modifiez la base de donnée (et uniquement lorsque vous savez que vous utilisez un mot interdit ce qui réduit considérablement le temps de vulnérabilité).
Je pense proposer un petit outil pour faciliter cette manipulation mais pas tout de suite.

[flipflip]

Salut, je viens de rencontrer le même problème avec le mot cascade. J'ai bien compris le pourquoi et je suis tout à fais d'accord pour que ça reste, il y a assez de synonymes en français pour contourner le problème. Au contraire il pourrait être intéressant de mettre un message d'avertissement plus clair sur la raison du blocage lors de la création d'un produit. Je pense notamment pour les clients non informaticiens.

[ludo]

ça serait pas plus simple de filtrer ces maudits mot uniquement dans les formulaires (recherche surtout) dans le frontoffice ?

Pour le backoffice, mince on est chez nous.. on va pas se pourrir notre propre site, alors franchement de ce coté la barrière cette interdiction perd tout son sens voir pire... elle handicape la bonne gestion du site. Exemple : vous pouvez pas indiquer le mot "Union européenne" dans le CMS... super pratique éditer ses CGV !

Pour l'instant, heureusement que SotEW a des gènes de Vick le Viking et nous a trouvé une jolie p'tite astuce.

A prendre en compte dans la v1.2 !
J'imagine aussi l'enfer que doivent vivre nos copains anglophones !!!
* UNION
* CASCADE
* ESCAPED
* TERMINATED
* TRIGGER
* REVOKE

Pour cela, ça doit pas gêner grand monde...
* X509
* LOAD_FILE
* OUTFILE
* DUMPFILE
* INFILE

[daYmo]

@ludo : +100

C'est quoi ce délire de blacklist dans le BO ! Franchement.....
Pis il suffit de donner des droits restreints aux user mysql pour ne rien risquer !

[StoreCommander]

Voici une astuce pour désactiver la blackliste dans le BO à utiliser A VOS RISQUES ET PÉRILS :

DANS /votreRepertoireAdmin/index.php


CHERCHER

if ($tab)
{
   if ($id_tab = checkingTab($tab))
   {

AJOUTER APRES

$blackListAccess=XXXX;

où XXXX est un nombre de 4 chiffres que vous prenez au hasard.


DANS /classes/DB.php

REMPLACER

   public static function blacklist(&$query)
   {
       return eregi(self::$_blacklist, $query) ? true : false;
   }

PAR

   public static function blacklist(&$query)
   {
       global $blackListAccess;
       if (isset($blackListAccess) && $blackListAccess==XXXX) return false;
       return eregi(self::$_blacklist, $query) ? true : false;
   }

où XXXX est le nombre que vous avez précédemment défini.

[daYmo]

Merci Vincent, c'est ce que j'avais fait également
Sauf que j'avais mis tout de même une blacklist dans le BO avec, en l'adaptant à ton code, un

       global $blackListAccess;
       if (isset($blackListAccess) && $blackListAccess==XXXX)  return eregi(self::$_blacklist_bo, $query) ? true : false;
       return eregi(self::$_blacklist, $query) ? true : false;

avec

private static $_blacklist_bo = 'LOAD_FILE|OUTFILE|DUMPFILE|ESCAPED|TERMINATED|INFILE|REVOKE';

[Guest]

Il n'y a plus qu'à utiliser le langage SMS pour contourner la Black List (désolé, j'ai pas pu m'retenir )

[Antoine Gomez]

Bonjour,

Je viens de rencontrer aussi ce problème.

L'idée d'une blacklist est bonne et je l'approuve.

Néanmoins je n'y vois pas de sens, en tout cas pour les champs textes remplis par les utilisateurs (VARCHAR, TEXT, CHAR ...).

Une Classe qui gère bien la DB, héritant de PDO, n'aurai besoin que d'utiliser la méthode "quote" de ce dernier ou alors la fonction mysql_real_escape_string.

Pour le reste de la requête elle est formée par les objets de Prestashop non ?

Donc si qqun essaye de faire une injection elle sera contrée grâce à la méthode/fonction quote/mysql_real_escape_string.

Et si vous faite ce genre de blacklist pourquoi prendre en compte "union" mais aussi "xxxxunion" et "xxxunionxxxxx".

Ce comportement n'est pas normal et doit être reporté comme bug et non "feature" nécessaire pour raison de sécurité.


Pourquoi faire simple alors que l'on peut faire compliqué a surement été votre devise pour cette fonctionnalité.

Sinon le reste est vraiment bien et l'utilisation d'un Prestashop est agréable.

[VMeche]

Une solution propre pour les mots interdits dans une requête SQL pourrait être de distinguer les "statements" des valeurs.
La blacklist ne serait alors appliquée que sur les statements.

Ca ne devrait pas être trop difficile car on dispose d'un discriminant : les valeurs "chaîne" sont entourées, alors que les statements ne le sont pas.

[Team Elodie]

Liste des mot 'interdit' qu'on as trouvé (en fait c'est des mots en union qui es interdit ^^)

-Communion
-Réunion
-union

sinon on peut les espacé exemple: C o m m u n i o n

J'espère que vous trouverais bientôt comment le résoudre :-S

[Fil]

Cette procédure est compréhensible en ce qui concerne les instruction SQL, et le moyens de les passer au moteur par les différents moyens possibles. Par contre, les chaine correctement quotées ne devraient effectivement pas être concernées, comme signalé précedemment.

Personnellement, je trouvais aussi qu'il était pénalisant pour les clients de ne pouvoir rechercher un produit tel que "statuette réunionaise", par exemple (Car cette limitation touchait aussi la recherche), ou d'avoir des client qui habitent à la réunion.

Alors j'ai apporté ma modif à la fonction Classes/DB.php/blacklist():

h3. Avant:

   public static function blacklist(&$query)
   {
       return eregi(self::$_blacklist, $query) ? true : false;
   }

h3. Après

   public static function blacklist(&$query)
   {
       // === Ajout Fil - 01/04/2009 13:45:47 ============================
       // Correction, non controle blacklist des contenus entre quotes dans le cas des REQ actives + select
       $query = trim($query);

       if (preg_match('/^(REPLACE|UPDATE|INSERT|SELECT) /', $query)) {
           // Prépare la requète
           $tmp = str_replace(array("''", "\'", ' ', "\t", "\n", "\r"), '', $query);

           // Vide les chaines
           $tmp = preg_replace('/\'[^\']*\'/','', $tmp);

           // Controle sur ce qui reste
           return eregi(self::$_blacklist, $tmp) ? true : false;
       }
       // === /Ajout Fil - 01/04/2009 13:45:47 ============================

       return eregi(self::$_blacklist, $query) ? true : false;
   }

Peu de perte de perf, et ca fonctionne, d'après mes essais en BO et en FO, seules les instructions SQL sont contrôlées.

[Patric]

A noter que cette blacklist a disparu avec la version 1.2.

[Philippe]

Merci pour l'info Zendik !

[Alekhine]

Il n'y a plus qu'à utiliser le langage SMS pour contourner la Black List (désolé, j'ai pas pu m'retenir )

lol ^^

Je tombe ici parce que je viens de créer un produit "Bougie Communion" haha...

Bon pour le moment c'est Communi0n (haha²)
Dommage que le message d'erreur ne soit pas explicite j'ai quand même cherché un moment :/

Je vais faire un DB___risk.php et un DB___orig.php

[oriflameFR]

C'est absolument incroyable ! MDR
Je viens d'avoir un appel d'une cliente qui essaie depuis une semaine de passer commande sur mon site et elle n'y arrive pas.
Heureusement qu'elle n'a pas changé d'avis et qu'elle m'a téléphoné!

Le problème : Impossible pour elle de renseigner son adresse et donc d'arriver à la page de paiement....

La raison : Madame habite rue de la Réunion....

et à chaque tentative pour inscrire son adresse elle avait droit à :"une erreur s'est produite pendant la mise à jour de l'adresse"

[Momiji]

Salut,

J'envoie aussi parfois vers La Réunion. Après avoir tourné en rond, j'ai créé "La Rénion" comme pays, puis je suis allé dans la BDD et j'ai corrigé la faute en éditant l'enregistrement.

Ai-je créé une faille de sécurité à l'insu de mon plein gré ?

[Patric]

Créé une faille de sécurité non, mais il faut espérer que cette valeur ne posera pas de problème plus tard, lors de l'utilisation de la boutique, si ce pays vient à être ajouté à la base de données d'une façon ou d'une autre... Mais je pense que ce sont plutôt les IDs qui sont généralement utilisés.

[Simone]

Bonjour !

Juste pour ma curiosité personnelle... Quand vous dites :

A noter que cette blacklist a disparu avec la version 1.2.

C'est que vous avez carrément abandonné l'idée de blacklister certains mots ou vous avez trouvé une autre solution ?
Car a priori l'idée de vérifier que ces mots se trouvent bien à l'intérieur d'une chaîne de caractère et donc que Mysql ne les considérera pas comme des mots clés, me semble être la meilleure solution et qui plus est assez facile à mettre en oeuvre....

Merci d'avance !

[huhamanu]

Bonjour !

Juste pour ma curiosité personnelle... Quand vous dites :

A noter que cette blacklist a disparu avec la version 1.2.

C'est que vous avez carrément abandonné l'idée de blacklister certains mots ou vous avez trouvé une autre solution ?
Car a priori l'idée de vérifier que ces mots se trouvent bien à l'intérieur d'une chaîne de caractère et donc que Mysql ne les considérera pas comme des mots clés, me semble être la meilleure solution et qui plus est assez facile à mettre en oeuvre....

Merci d'avance !

Simple problème de quotes effectivement...
Personne de chez prestashop pour répondre à la question de Simone?

[Patric]

Nous n'avons pas conservé cette liste gênante pendant des mois pour finalement créer des trous de sécurité.
Un autre moyen à donc été mis en place.

[huhamanu]

Heureusement oui...
Pour ceux qui sont sous des versions 1.1 est-il possible de corriger ce problème sans faire de mise à jour vers une 1.3?
Comme par exemple changer juste la classe Db.php ou une fonction...?

[Uniraph]

Je viens d'avoir exactement le même problème avec quelqu'un qui habite justement:
"** rue de la Réunion"
J'ai donc palier le problème en l'inscrivant dans la BDD.
En revanche, y a t'il un palliatif pour ceux qui sont en v1.1 ? (sans passer en 1.3)