Après avoir acheté du fromage au supermarché Coop, j'ai réalisé plus tard que l'étiquette contenait du texte un peu spécial. En effet dans le champ de description du fromage il y avait inclus 2 requêtes de base de donnée en langage SQL, qui n'ont normalement rien à faire là. On peut les voir sur le scan de l'étiquette que j'ai effectué ci-dessous.
Pour ceux qui n'ont pas la lecture « informatique », les requêtes SQL sont celles-ci :
select * from PR_ITEM_CONTENT(8,3068)select * from PR_ITEM_NUTRITIONAL(1,8,3068,5,'Valeurs nutritives moyennes pour 100 g')
Explication, et suppositions sur les erreurs éventuelles et leur niveau dans la chaîne de production
Le travail dans les failles de sécurité permet de deviner comment cela à pu arriver. À la fin des requêtes, il devrait normalement y avoir un point virgule (;), qui aurait pu être supprimé par des nettoyages de texte lors de l'importation des données depuis la base de donnée. Mais le fait que les données de contenu descriptif et de valeurs nutritionnelles ne soient pas présents, mais à leur place leurs requêtes SQL pour les obtenir, montre que lors de l'insertion du code dans le programme, ou de l'utilisation de celui-ci pour remplir la base de donnée, le programmeur a dû faire une erreur de frappe ou un oubli, Il a dû justement oublié le point virgule de fin, ce qui fait que la requête SQL n'a pas été exécutée, mais a été détectée comme champ texte « normal » à mettre tel quel dans la base de donnée.
Il n'est pas facile de savoir si la base de donnée en question est celle de la Coop, et donc l'étiqueteuse qui s'en sert pour créer les étiquettes, où même si la base de donnée est celle du fabriquant du fromage AOP, et que la Coop n'ajoute dans son descriptif que le descriptif fourni par le producteur. Dans ce 2e cas, il y a eu au moins 2 erreurs humaines, la première du programmeur, et la seconde des employés de la Coop qui ont inséré dans la base de donnée des étiqueteuses, les données fournies par les producteurs et ce sans vérifier s'il y avait des erreurs de contenus. Dans le 1er cas, 2 erreurs sont aussi envisageables, soit la 2e, celle du responsable de rayon, qui fait mettre les étiquettes sans vérifier si les contenus textes sont justes ou même on du sens …
Analyse technique plus détaillée
Les 2 noms après le « from » indique les noms des tables dans la base de données pour stocker les informations du produit (PR_ITEM_CONTENT, PR_ITEM_NUTRITIONAL). La recherche sur les moteurs web ne donne pas plus d'informations, mais des personnes travaillant dans le domaine pourraient en identifier un type de base de donnée en relation à une application métier spécifique, et donc préciser la chaîne d'erreur(s).
2 identifiants sont les mêmes dans les 2 requêtes (8,3068), on peut vraisemblablement supposer qu'il s'agit de la clé de produit, une clé double, soit par exemple une clé de catégorie de produit et une clé de produit lui-même, soit 3068, notre fameux fromage « Abondance ».
Il est possible de donner d'autres d'informations techniques sur ces requêtes. Tout d'abord elles ne semblent pas « standard ». En effet il faudrait une clause « WHERE » pour sélectionner l'entrée avec une valeur de clé. Cependant certaines bases de données permettent ces requêtes sans clause « WHERE » où des vecteurs sont données directement entre parenthèses. Donc avec l'analyse plus poussée de la typologie de requête il est possible d'identifier quel type de base de données est utilisé pour le stockage des données où à eu lieu l'erreur.
Voir plus de détails à ce sujet, paragraphe « Conforming Alternatives »
https://modern-sql.com/use-case/select-without-from#conforming-alternatives
Le(s) précédent(s)
Ce genre d'erreur sur les étiquettes de produits, semble ne pas être nouveau, une autre personne a trouvé la même erreur sur un produit de supermarché Suisse (ici nous n'avons pas le nom du super marché), mais le look est identique à l'étiquette de la Coop ci-dessus.
Voir tweet à ce sujet :
https://twitter.com/lesjoiesducode/status/1414970303113990150
Ce qu'on peut retirer
Ici cette étiquette n'est pas vraiment une faille de sécurité. En effet elle ne donne pas vraiment d'information pour pirater un système de la Coop ou du producteur. Donc avertir le vendeur avant de publier un article comme celui-ci n'est vraisemblablement pas nécessaire. Cependant cette anecdote de plus, montre une fois encore le fait que les erreurs de programmation et éventuellement des failles de sécurité, sont partout. Malgré les tests de validations, les systèmes qualités et surveillances, les discours des responsables informatique, la norme est l'erreur humaine. Notre système est un système où tout devient numérique, de plus automatisé, et ce à chaque échelon. Mais la majorité des employés ne sont pas des programmeurs avertis. Et même les programmeurs avertis finissent par devenir en trop petit nombre à devoir tout surveiller à propos de tout. Dans ces circonstances, il y a de grandes chances pour que des erreurs sortent dans le public comme celle-ci de plus en plus souvent, et de plus en plus à propos de tout ce qu'on peut rencontrer comme produits, services, loisirs, dans la vie de tous les jours. Pour éviter ceci, il faudrait déjà que les responsables qualité des chaînes de vente ne deviennent plus des juristes, mais soient des spécialistes de sécurité informatique …
De plus le hasard métaphorique et poétique veut que le nom du fromage soit « Abondance ». Quel meilleur nom de produit pour illustrer l'abondance des failles humaines et informatiques dans la gestion de tout ce qui croise notre vie … 😀