Discussion :

[mpirard]

Bonjour à tous,

Je suis un ancien programmeur qui se remet à jour après longtemps. J'étudie en ce moment les connexions BDD à partir d'une application PHP. J'ai un peu étudié PHP et les frameworks. Je me suis rendu compte que la connexion BDD est faite à partir d'un fichier, éventuellement crypté, avec un seul utilisateur. Tout le monde a l'air de trouver ca normal. Je me trompe peut-être mais ça ne me parait pas trés sécurisé. D'abord que l'utilisateur et le mot de passe se trouve dans un fichier.

Ensuite, la plupart des applications sur internet ont l'air de se contenter d'un seul utilisateur BDD. Toutes les données sont accessibles au niveau SQL par cet unique utilisateur. (Même si les modules de l'application ne le sont pas et que les données sont limitées par la programmation PHP selon la session.)

La sécurité des données est-elle meilleure en PHP qu'en SQL?
Si il n'y a qu'un seul utilisateur BDD qui accède à tout, à quoi servent les privilèges SQL (GRANT,...)?

Si je veux développer une application online, ne serait-ce pas mieux de se connecter directement avec un véritable utilisateur BDD avec ses propres privilèges BDD? Ca éviterait d'établir d'abord la connexion BDD et ensuite déterminer ses accès par l'application PHP, les sessions,...

Ou alors passer par une BDD tampon qui ne ferait que la gestion des utilisateurs et des accès? Qui ferait le lien entre l'utilisateur session et l'utilisateur BDD? Je risque alors de me retrouver devant le même problème, comment me connecter en toute sécurité à cette BDD tampon?

J'aimerais beaucoup avoir vos avis à ce propos.

Merci d'avance,

Marc

[sabotage]

Ca éviterait d'établir d'abord la connexion BDD et ensuite déterminer ses accès par l'application PHP, les sessions,...

Il faudra dans tous les cas bien faire une connexion à la BDD, utiliser des sessions et déterminer des droits au niveau de l'application.

Je pense qu'on se contente d'un seul utilisateur pour plusieurs raisons :
- les hebergements ne permettent pas forcemment la création d'utilisateurs BDD
- l'avantage sécurité reste faible : par exemple imaginons que je souhaite n'autoriser à l'utilisateur classique qu'un accès en lecture à la table utilisateur ... pour qu'il puisse s'inscrire sur le site, il aura bien fallu qu'il y ait eu un accès écriture à la table utilisateur, à la table des droits etc. alors qu'il n'était même pas encore connecté.

La sécurité des données est-elle meilleure en PHP qu'en SQL?

Si la sécurité est mauvaise en PHP, la BDD de donnée est de toute façon compromise.
Si je prévoit des droits BDD différents pour un utilisateur ou un administrateur mais que ma sécurité PHP permet de toute façon de se faire passer par un administrateur, mon droit BDD ne limite rien.

[mpirard]

Merci pour votre réponse rapide, sabotage.

J'ai oublié de préciser que les applications que je pense développer seraient seulement accessibles par des utilisateurs avertis créés par l'administrateur. Donc, sans possibilité de s'enregistrer soi-même, le mot de passe étant donné par l'administrateur.

Dans ce cadre ci, si je sécurise bien PHP et que l'hébergeur me permet de créer mes utilisateurs BDD, n'est-ce pas plus sécurisé de se connecter directement avec le login BDD? Le mot de passe ne se trouverait dans aucun fichier hormis la BDD et l'utilisateur serait limité par ses privilèges au niveau BDD.

Ou bien:
Si je n'ai que quelques niveaux de sécurité mais beaucoup d'utilisateurs de l'application, je pourrais faire un fichier faisant correspondre plusieurs utilisateurs de l'application avec un utilisateur BDD (un par niveau de sécurité)? Le fichier serait lu avant la connexion BDD et ne comporterait aucun mot de passe.

[sabotage]

Je ne comprends pas bien ton histoire de connexion sans mot de passe.

[mpirard]

Le mot de passe est présent. Mais il est donné à l'utilisateur par l'administrateur, il se trouve uniquement dans la table des utilisateurs de la BDD (table user dans MySQL). Par contre, il n'y a plus de mot de passe dans un fichier texte.

Mais mon cas est particulier dans le sens où l'application s'adresse à une société fermée (une banque par exemple). Ici, personne ne va s'enregistrer et créer son propre mot de passe. Chaque utilisateur est averti personnellement de son login et mot de passe.

[sabotage]

Ca n'est possible que dans le cas ou tu crées un utilisateur BDD par utilisateur de l'application.
Et d'ailleurs ce n'est peut être pas tout a fait vrai : pour établir la connexion BDD avec le mot de passe saisi par l'utilisateur, tu devras stocker ce qu'il a saisi quelque part ... problablement dans une session PHP, et donc le mot de passe finira écrit dans un fichier sur le serveur.