Discussion :

[Xurudragon]

Comme je m'y connais la dessus (je suis ces histoires de près !), je me permets d'intervenir. Effectivement, le SGBD n'est pas la source de la faille. Mais la faille est une conséquence du manque de fonctionnalités du SGBD choisi.

Le coup du mot de passe stockée en clair par exemple, il faut vraiment le faire exprès avec un SGBD comme SQL Server pour le faire (car il propose les fonctionnalités qui vont bien). Mais il est difficile de faire autrement en utilisant MySQL.

Je ne suis pas d'accord, MySQL propose aussi des fonctionnalités pour "chiffrer" les mots de passe, et autre données, je pense notamment à PASSWORD(), ENCRYPT(), AES/DES_ENCRYPT(), ASYMMETRIC_ENCRYPT(), etc... .
(Ces fonctions génèrent des chaînes binaire illisible tel que ˜¯(o 2¤®QŠ¦”jD,=ET£9Z! )
Mais quand bien même un SGBD ne proposerai pas de chiffrer/hasher nativement, c'est encore une fois la responsabilité première des applicatifs/développeurs de faire le nécessaire, dans un premier temps, côté code.

[Christophe]

Mais quand bien même un SGBD ne proposerai pas de chiffrer/hasher nativement, c'est encore une fois la responsabilité première des applicatifs/développeurs de faire le nécessaire dans premier temps côté code.

Surtout qu''en PHP, il y a ce qu'il faut en fonctionnalités.

Comme je m'y connais la dessus (je suis ces histoires de près !), je me permets d'intervenir. Effectivement, le SGBD n'est pas la source de la faille. Mais la faille est une conséquence du manque de fonctionnalités du SGBD choisi.

En quoi laisser l'accès à des données d'un utilisateur lambda depuis un autre utilisateur via une URL est une conséquence d'un manque de fonctionnalité du SGBD ? Là je ne comprend pas.

[Xurudragon]

Surtout qu''en PHP, il y a ce qu'il faut en fonctionnalités.

En PHP, ou autres techno, il y a largement ce qu'il faut. Comme la libraire Sodium/Argon2i etc...
bref

[Bardotj]

Haha le sujet bien troll.

tout d’abord je ne comprends pas très bien ce que viennent faire des phrases comme :

Pour cela les grands éditeurs (Oracle, Microsoft SQL Server) proposent une méthode globale appelée TDE (Transparent Data Encryption) pour chiffrer de manière élégante et sans impact sur les performances relationnelles, la totalité des données de la base. Cette technologie est hors de portée du monde libre.

Pourquoi cette technologie est hors de portée du monde libre ?

De plus même si je vois tout a fait et comprend les points mis en avant il serait

1 juste de remettre dans le contexte économico-temporel (comme exprimé par d’autre)
2 bien plus utile de rédiger ces griefs/problèmes dans un courriel en anglais a destination des mailings list des dits sgbd.

Et dans un monde de plus en plus pauvre et régit par la «*loi*» du marché il ne faut pas s’étonner de voir les gens/sociétés fuir les gros éditeurs qui malgré tout se gavent bien et détournent des fonds a tour de bras.

Il est question de chiffrement, donc de sécurité, donc de confiance.
Je suis désolé de dire que je ne fais pas confiance a Microsoft ni au logiciel propriétaire.

- Microsoft car l’état américain se sert d’eux dans sa guéguerre puérile de la conquête du monde. Notamment pour couler/faire pression sur les concurrents etc (voir publication des journalistes et des lanceurs d’alertes) on peut parler des cloud act, etc.
- Factuellement on ne sait pas facilement ce que les logiciels propriétaires font de nos données et il est difficile (impossible) pour le développeur lambda de pouvoir auditer le code. (vous avez dit rgpd)

C’est un risque que je déconseille de prendre a des sociétés qui souhaitent survivre, lancer des produits a l’international ou se mettre sur un secteur ou il existe des sociétés américaines.

Comme a mon habitude plein de fautes, je m’en excuse.

[stephweb]

MySQL/MariaDB a la fâcheuse tendance à renvoyer n’importe quoi sans jamais émettre d’erreur dans le cas où la clause GROUP BY est incomplète, donnant des résultats hasardeux presque toujours faux !

Avec MariaDB 10.3 (et il me semble que déjà avec quelques sous-versions/versions en dessous aussi), on n'a pas ce problème.

On a une erreur de ce style : Syntax error or access violation: 1055 '{DB_NAME}.{TABLE-NAME}.{COLUMN_NAME}' isn't in GROUP BY

[Invité]

Bonjour,

Dans les truc farfelus de mysql j'ai trouvé ceci :

Créez une table ou vous injectez automatiquement de la data. Votre clef est un autoincremente. L'autoincremente a une gestion désastreuse des numéros ... Vous insérez 10000 lignes , votre compteur passe de 5000 à 7000 sans raison vous arrivez donc à 12000 .

Vous pensez au final avoir 12000 , erreur ! Vous en avez bien 10000 ... Pourquoi un tel comportement ? L'autoincremente n'est pas au point.

C'est dangereux car le compteur de l'incremente est "trompeur" . Se retrouver avec des "trou" dans une numérotation censé être logique est assez ubuesque pour un SGBD ...

[stephweb]

C'est dangereux car le compteur de l'incremente est "trompeur" . Se retrouver avec des "trou" dans une numérotation censé être logique est assez ubuesque pour un SGBD ...

C'est vrai que l'auto-incrémentation de MySQL (et aussi de MariaDB 10.3) peut de temps à autre être trompeur.

C'est pour cette raison qu'il ne faut jamais utiliser l'id pour les numérotations de facture.
Je m'explique :
Imaginons qu’on utilise MySQL ou MariaDB et qu’on utilise les transaction, et qu’un membre valide une commande et que la transaction échoue pour lui, et que juste après un autre membre valide sa commande et qu’avec lui la transaction n’échoue pas : le résultat est qu’on aura un trou dans le numérotation (exemple : l’id passera de 100 à 102, la facture numéro 101 sera donc manquante, et en France on a pas le droit d’avoir de trou dans la numérotation de factures).

Et même pour toute autre numérotation je déconseille d'utiliser l'id (numéro de devis, numéro clients, numéro des SAV, etc.).

Pour détourner ce "problème", pour résumé je fais ceci :
Perso j'utiliser une table spécialement créée pour les systèmes de compteur. Et dans cette table j'ai une ligne pour chaque module pour lesquels j'ai besoin d'un compteur (sans trou). Et pour les tables des modules dans lesquels je veux un système de compteur (sans trou) j'ajoute une colonne integer spécialement pour indiquer le numéro de la ligne.
Et lorsque je fait un INSERT d'une nouvelle ligne (d'une nouvelle facture par exemple) : j'ouvre abord une transaction et je fait un SELECT ... FOR UPDATE, et ensuite je fait mon INSERT + j'incrémente la compteur (dans la table créée spécialement pour) + éventuellement quelques autres req SQL avant de valider la transaction.

[Christophe]

Pour cela les grands éditeurs (Oracle, Microsoft SQL Server) proposent une méthode globale appelée TDE (Transparent Data Encryption) pour chiffrer de manière élégante et sans impact sur les performances relationnelles, la totalité des données de la base. Cette technologie est hors de portée du monde libre.

Le TDE est disponible sur la version commerciale de MySQL.
Ca semble disponible aussi avec MariaDB.
Je n'ai pas la compétence pour juger ce que ça vaut par rapport à Oracle ou SQL Server.

[escartefigue]

Pour moi, MySQL/MariaDB est/sont l'un des SGBD qui évolue le plus rapidement.

Je pense qu'il convient de rappeler que MySQL / MariaDB viennent à peine d'intégrer les CTE et autres apports de la norme SQL de ... 1999 soit avec presque 20 ans de retard ! Ils ont fait à peine mieux concernant les fonctions fenêtrées puisque ca n'a pris que ... 10 ans EDIT 15 ans puisque les fonctions fenêtrées sont un apport de la version SQL 2003

[Xurudragon]

Je pense qu'il convient de rappeler que MySQL / MariaDB viennent à peine d'intégrer les CTE et autres apports de la norme SQL de ... 1999 soit avec presque 20 ans de retard ! Ils ont fait à peine mieux concernant les fonctions fenêtrées puisque ca n'a pris que ... 10 ans

Certes mais qui utilise réellement toutes ces fonctionnalités de la norme SQL ? d'ailleurs on en parle niveau normalisation des différences de syntaxe entre tous les SGBD ?

En général on lui demande d'être relativement performant, simple à utiliser et à configurer.
Quand au reste c'est du plus spécifique et totalement faisable (clusterisation etc... mais là, tout comme pour les autres SGBD, ça se complexifie forcément)

[escartefigue]

C'est vrai que l'auto-incrémentation de MySQL (et aussi de MariaDB 10.3) peut de temps à autre être trompeur.

C'est pour cette raison qu'il ne faut jamais utiliser l'id pour les numérotations de facture.
Je m'explique :
Imaginons qu’on utilise MySQL ou MariaDB et qu’on utilise les transaction, et qu’un membre valide une commande et que la transaction échoue pour lui, et que juste après un autre membre valide sa commande et qu’avec lui la transaction n’échoue pas : le résultat est qu’on aura un trou dans le numérotation (exemple : l’id passera de 100 à 102, la facture numéro 101 sera donc manquante, et en France on a pas le droit d’avoir de trou dans la numérotation de factures).

Et même pour toute autre numérotation je déconseille d'utiliser l'id (numéro de devis, numéro clients, numéro des SAV, etc.).

Pour détourner ce "problème", pour résumé je fais ceci :
Perso j'utiliser une table spécialement créée pour les systèmes de compteur. Et dans cette table j'ai une ligne pour chaque module pour lesquels j'ai besoin d'un compteur (sans trou). Et pour les tables des modules dans lesquels je veux un système de compteur (sans trou) j'ajoute une colonne integer spécialement pour indiquer le numéro de la ligne.
Et lorsque je fait un INSERT d'une nouvelle ligne (d'une nouvelle facture par exemple) : j'ouvre abord une transaction et je fait un SELECT ... FOR UPDATE, et ensuite je fait mon INSERT + j'incrémente la compteur (dans la table créée spécialement pour) + éventuellement quelques autres req SQL avant de valider la transaction.

Les trous de numérotation des ID calculés par le SGBD (auto_incrément pour MySQL, sequence ou identity column dans d'autres SGBD) ne sont pas une spécificité de MySQL.
Quelque soit le SGBD, il ne faut jamais utiliser un identifiant attribué par le SGBD comme identifiant fonctionnel, ni pour numéroter des factures ni pour quelque autre usage que ce soit.
Pour rappel, ces identifiants techniques peuvent non seulement comporter des trous, mais également ne pas être commités chronologiquement
Il est tout à fait possible, tout à fait normal et même relativement fréquent, surtout en environnement multi-threads fortement concurrentiel, que l'identifiant n°105 soit enregistré avant l'identifiant n° 100 par exemple

[stephweb]

Les trous de numérotation des ID calculés par le SGBD (auto_incrément pour MySQL, sequence ou identity column dans d'autres SGBD) ne sont pas une spécificité de MySQL.
Quelque soit le SGBD, il ne faut jamais utiliser un identifiant attribué par le SGBD comme identifiant fonctionnel, ni pour numéroter des factures ni pour quelque autre usage que ce soit.
Pour rappel, ces identifiants techniques peuvent non seulement comporter des trous, mais également ne pas être commités chronologiquement
Il est tout à fait possible, tout à fait normal et même relativement fréquent, surtout en environnement multi-threads fortement concurrentiel, que l'identifiant n°105 soit enregistré avant l'identifiant n° 100 par exemple

Yes.
Mais beaucoup de dév utilisent les id pour les numérotations de factures.

[Xurudragon]

Yes.
Mais beaucoup de dév utilisent les id pour les numérotations de factures.

Mais là ce n'est, encore une fois, pas un problème de SGBD, mais un problème de connaissance du/des développeurs

[escartefigue]

Certes mais qui utilise réellement toutes ces fonctionnalités de la norme SQL ? d'ailleurs on en parle niveau normalisation des différences de syntaxe entre tous les SGBD ?

En général on lui demande d'être relativement performant, simple à utiliser et à configurer.
Quand au reste c'est du plus spécifique et totalement faisable (clusterisation etc... mais là, tout comme pour les autres SGBD, ça se complexifie forcément)

Les CTE sont un apport énorme dont l'usage est quasi quotidien, sans parler des requêtes récursives, d'usage certes moins fréquent, mais qui ne peuvent fonctionner qu'avec les CTE

Les fonctions fenêtrées sont également extrêmement utiles dans bien des cas et permettent parfois des solutions plus performantes que sans fonction fenêtrées (mesures à l'appui).

Mais je voulais surtout relever que votre affirmation

Pour moi, MySQL/MariaDB est/sont l'un des SGBD qui évoluent le plus rapidement.

est une contre-vérité : respectivement 20 ans et 15 ans pour suivre les évolutions, c'est gigantesque !

PS : j'en profite pour corriger en vert votre citation, on ne se refait pas, le sujet de "évoluent" est "les SGBD"

[François DORIN]

En quoi laisser l'accès à des données d'un utilisateur lambda depuis un autre utilisateur via une URL est une conséquence d'un manque de fonctionnalité du SGBD ? Là je ne comprend pas.

Si tu ne stockes pas tes données dans une BD, tu les stockes très certaines dans un fichier. Fichier qui se trouve dans un répertoire. Fichier qui, par fainéantise, est accessible directement par une URL (mettons "http://monsitepassur.org/fichiers/carte_vital.pdf", en HTTP histoire d'enfoncer le clou ).

Quand tu es une quiche en configuration Apache (ou Nginx ou autres hein !), le dossier est "navigable" depuis n'importe quel navigateur. Et donc, en ayant l'URL d'un fichier, si on retire juste le fichier et que l'on saisie "http://monsitepassur.org/fichiers", tu vas avoir l'intégralité des fichiers présents dans le répertoire.

Quand tu stockes toutes tes données en BD (les fichiers y compris donc), cette situation n'est pas possible, sauf à le vouloir volontairement.

[stephweb]

Si tu ne stockes pas tes données dans une BD, tu les stockes très certaines dans un fichier. Fichier qui se trouve dans un répertoire. Fichier qui, par fainéantise, est accessible directement par une URL (mettons "http://monsitepassur.org/fichiers/carte_vital.pdf", en HTTP histoire d'enfoncer le clou ).

Quand tu es une quiche en configuration Apache (ou Nginx ou autres hein !), le dossier est "navigable" depuis n'importe quel navigateur. Et donc, en ayant l'URL d'un fichier, si on retire juste le fichier et que l'on saisie "http://monsitepassur.org/fichiers", tu vas avoir l'intégralité des fichiers présents dans le répertoire.

Quand tu stockes toutes tes données en BD (les fichiers y compris donc), cette situation n'est pas possible, sauf à le vouloir volontairement.

Les fichiers sensibles, il ne faut certainement pas qu'ils soient accessibles via l'URL par tout le monde, il ne faut donc pas les mettre dans un répertoire public.
Si on ne veut pas les mettre en BDD, il faut les mettre dans un répertoire de storage qui n'est pas accessible par tout le monde via l'URL.
Et lorsqu'un utilisateur loggé (qui a les droits d'accès) veut voir le fichier via l'URL, on charge le fichier en PHP (en vérifiant les droits de l'utilisateur juste avant).

[François DORIN]

Les fichiers sensibles, il ne faut certainement pas qu'ils soient accessibles via l'URL par tout le monde, il ne faut donc pas les mettre dans un répertoire public.

Si tu suis bien la conversation, ce n'est pas moi qu'il faut convaincre Ce n'était qu'un exemple.

Mais je vois tellement ça dans mon boulot.... Et la CNIL aussi semble-t-il ! Y compris dans des projets réalisés par de grandes ESN...

[Christophe]

@François, ok je comprend mieux ce que tu voulais dire.

[Nibel]

J'aurai quand même toujours plus confiance en un logiciel libre qu'en n'importe quelle boîte noire propriétaire. Je peux maintenir le code et je sais ce qu'il s'y passe.

C'est simplement indispensable. A partir de là, les SGDB proprios sont nécessairement mauvais et dangereux selon moi, peu importe leurs qualités intrinsèques.

[DarkCenobyte]

Malgré des vérités, l'article ne paraît pas vraiment neutre:

1- Sur la disparition des tables, j'ai envie de dire que qui touche à des fichiers sur son disque, s'expose à des ennuis. (ça ne m'étonnerait pas que quelqu'un parvienne à altérer davantage un fichier catalogue pour faire mentir une base SQL Server ou autre, comme l'on peut altérer le mapping XML d'un Excel .xlsx ou ses données et paramètres en l'ouvrant comme un Zip et en altérant les fichiers .xml qui le compose).

2- Sur la validation des transactions, il est vrai que je ne fais aucune confiance à un ROLLBACK. Cela dit, il existe des alternatives bien plus safe dans un contexte de simulation comme utiliser des tables temporaires imitant une table différente (en la créant LIKE la table voulu, ...), ou même en jouant avec des partitions. (Utiliser une table identique non partitionné, jouer avec et requêter dessus pour la simulation, utiliser la feature ALTER TABLE ... EXCHANGE PARTITION au moment où l'on veux la figer dans la table définitive partitionné, sans aucun temps de latence due à cette action). (Bon j'accorderais qu'il est possible de faire mentir ENCORE PLUS MySQL avec la logique des partitions... Mais quand on sait bien l'exploiter, il y a des usages très intéressants je trouve).

3- schema vs database, c'est un peu faire un procès aux abus de langage pour une feature non supporté mais accepté au nom de l'interopérabilité du code SQL. Comme on ne peut pas faire d'index DESC, ou que certains keywords sont sans effets pour MySQL malgré qu'il les acceptes.

4- Pour les statistiques fausses, je considère qu'il est la responsabilité du développeur de se rendre compte du résultat de ce qu'il a exécuté comme requête, et de la cohérence des données. Alors oui MySQL pourrait faire "met tout en group by !!!", mais maintenant, avouons que si j'écris:
SELECT A, B, SUM(C) FROM X WHERE B = 1 GROUP BY A;
Il semble peu utile d'avoir à group by A,B ou d'avoir à faire un MAX(B) dans l'unique but de satisfaire le SGBD (chose qui serait réclamer par d'autres SGBD).
C'est une histoire de comportement plus ou moins strict, mais je pense que le développeur faisant un GROUP BY n'est pas censé le faire pour décoré et doit savoir ce qu'il fait et ce que fait la technologie qu'il utilise. Si les données lui mente, à lui d'être rigoureux et de group by correctement.
De plus il y a la configuration "ONLY_FULL_GROUP_BY" qui peut être ajouté, pour rendre MySQL plus strict.

5- Comme déjà mentionné pour la sauvegarde, la solution de Percona XtraBackup fait l'affaire et gratuitement.

6- Défense du libre, en-dehors d'avoir à trainer les faibles priorités de la part de Oracle & co (car ils faut bien vendre des versions payante ou privilégié les bdd Oracle de la maison...), elles ont permis la naissance du fork MariaDb (qui n'est pas que décoratif et apporte des lots d'optimisation et d'amélioration en terme de sécurité entre autre, ... Et dispose également d'un bon moteur de performance au delà du InnoDB), des solutions de Percona (mieux optimisé et avec de bons outils), des forks RDS Aurora par Amazon (qui a ses solutions de sécurité, de sauvegarde, de ses optimisations maisons, ses tricks permettant sous conditions de faire des alter table instantané pour des ajouts de colonnes... Et une intégration très avancé avec leur service S3 s'hybridant à l'import/export avec des fichiers CSV (load from / into outfile), et même des lambdas (permettant d'exécuter du code dans n'importe quel langage aujourd'hui, de façon synchrone ou asynchrone, pour notifier d'une action ou recevoir une information extérieur dans un process à l'intérieur de la base de données) et enfin de supporter mieux des bases de données de plus de 1To).


Je trouve que l'article charge un peu trop MySQL, sans chercher à être toujours 100% objectif.