Discussion :

[satriani94]

Bonjour,
Je viens de donner un GRANT à un client en SELECT seulement sur une table. Tout marche bien, il n'arrive pas à utiliser les autres instructions (insert, update, delete). C'est super bien mais........
il arrive à lire la structure de la table ! Ce que je n'aime pas trop car ça donne beaucoup d'infos pour les hackers. Ma base de données est sollicité directement par des clients...
Comment faire ?

[ced]

Bonjour,

Le catalogue MySQL donne des droits de lecture dès lors qu'un utilisateur possède un droit SELECT dessus, ce qui paraît normal. Sinon, comment fait-il pour connaître la liste des colonnes d'une table qu'il peut lire ?

Et très franchement, concernant le "hacker", il ne passera pas par un compte utilisateur qui n'a que des droits de lecture sur une table et dont il ne connait pas le nom a priori.
Non ! Il a tout intérêt à passer par le compte "root", qui a tous les droits (selon le paramétrage par défaut d'un serveur MySQL), et dont le nom est connu à l'avance de tous.
C'est sur ce compte-là qu'il faut faire porter les efforts, pas sur un compte utilisateur lambda, qui plus est avec seulement des droits en SELECT.

[satriani94]

C'est vrai qu'un utilisateur doit savoir la liste des colonnes pour utiliser un SELECT, mais pas forcement de savoir que je donne un "VARCHAR 50" au 'Prénom' ou un timestamp à ma date....cela lui permettra de recréer la table s'il le veut... et même recréer la base de données s'il a un SELECT sur toute la base !!!!! et il y a des gens qui ne veulent pas ça !!!
Alors l'idée c'est quoi ? Je réponds avec une nouvelle approche qui est de présenter un nouveau concept de privilèges qui est SELECT ONLY ET LE SELECT qu'on connait comme d'habitude... alors : avec le select only ou update only ou insert only ou delete only...on peut voir la listes de colonnes mais pas la structure interne de la table (type de colonne, combien de varchar, int ou real etc..) d'où + de confidentialité et + de maîtrise des droits et personne ne peut reproduire tes tables ou ta base de données...
Pensez à déposer un brevet pour moi

[ced]

Désolé, mais je ne vois toujours pas l'intérêt de la chose.
A partir du moment où j'autorise un utilisateur à faire une requête sur une table, je l'autorise potentiellement à exporter toutes les données contenues dans cette table. Et donc à la reconstruire où il veut.
Et franchement, que telle ou telle colonne soit du VARCHAR(10) ou VARCHAR(50)... tant que le nombre de caractères rentre, il s'en moque...

Et il est sûrement préférable de voir l'architecture d'une table que son contenu, en termes de confidentialité.

Là où la démarche peut se concevoir, c'est de donner un accès au contenu de certaines colonnes d'une table, mais pas toutes. Et là aussi, que l'utilisateur sache qu'une colonne dont il ne peut pas lire le contenu est de type INT, VARCHAR, DATETIME, etc. n'a aucune espèce d'importance, puisqu'il ne peut pas en lire le contenu (donc la donnée)...
Mais ça, je ne suis pas du tout sûr que les versions les plus récentes de MySQL sachent le faire (à vérifier).

ced

[satriani94]

Regarde bien…
J’ai construit une base de données dont le SELECT est autorisé aux autres... ok
La base de données a un accès direct et via le web.
Maintenant, quelqu'un vient de voir la structure de la table et il a les info suivantes :
DIA ,NOMATI,PRENATIO,SALRITI….et que ma base de données s’appelle « bdd1 »... alors que sur la page web j’affiche ID,NOM,PRENOM,SALAIRE (pour cacher les vrais noms des champs de ma base). Pour un hacker, c’est la fête car maintenant, il peut commencer à essayer des injections SQL sur cette base dont il connait toute la structure… et parmi les choses les plus importantes dans la création web figure le fait de ne pas afficher les erreurs de connexion à une base, pour ne pas donner de possibilité aux hackers d’introduire de l’injection SQL. Je t’invite de réviser les bases de la sécurité web…
Et tu donnes même la structure MCD de ton travail, car si je connais la structure totale de tes tables et que j'aperçois où sont les clés étrangères et tout… alors je reconstruis ton travail facilement d’où ton MCD… d’où la confidentialité intellectuelle.
Le concept de cacher la structure est très très très important.

[ced]

Là, vous décalez et généralisez le problème.
La question initiale portait sur les droits de SELECT sur une table.
Le problème de l'injection SQL est plus global et n'est pas le (seul) fait des règles d'affichage des noms de colonnes d'une table dès lors qu'on y a accès en SELECT.

Cela fait intervenir la configuration PHP, les accès à plusieurs tables dont les tables de la base "mysql", etc...

Ce n'est plus la même question.

[satriani94]

Je viens de participer à la webminar de MYSQL qui s'est déroulée à 17:00 GMT, et je leur ai proposé l'idée, et crois-moi CED... ils ont été très intéressés par ce concept. Merci ced pour tous les messages et l'intérêt que tu donnes a mes posts. Je mets ce message comme résolu..