Bonjour,
Nouveau sur le forum.
J'ai un projet avec CakePHP3 et je cherche à connaître la meilleure pratique dans ce contexte. Je sais que je dois faire un compte de base dans MySQL et protéger "ROOT", mais je me demandais si je devrais faire plus d'une connexion à la base de donnée avec des permissions différentes pour les différents rôles sur le site; Invités, Membres, Modérateurs, ou si je perderais mon temps avec la sécurité qu'offre CakePHP3.
Merci.
CakePHP offre suffisamment de protection (ça serait un comble sinon, au vue du nombre de grosses boites qui s'en servent), seul la façon de t'en servir pourrait provoquer des failles aussi basique. Après, utiliser l'utilisateur ROOT n'est pas non plus recommandé (tout comme on n'utilise pas le root pour gérer un serveur).
Je trouve que je me complique souvent la vie, mais là, tu fais fort :)
Généralement, la sécurité de la DB se fait coté serveur, par exemple ne pas utiliser phpmyadmin pour administrer sa base, mais des outils de connexion distante comme sequel pro ou autre.
Côté PHP la seule chose qui te permet de gérer la sécurité c'est ta gestion utilisateur. Généralement les personnes sans aucun niveau de sécurité dans mes applications ou site n'ont accès a qu'as la lecture d'info en Db.
Je suis d'accord sur ce point, mais ça permet aussi de sécurité l'accès à la soumission du formulaire.
De toute façon, pour pallier a une injection SQL ce n'est pas en ayant plusieurs connexions différentes, mais en validant les données côté PHP avant enregistrement en DB.
Bref tout ça pour dire que déjà ROOT on oublie pour la DB et pour l'accès SSH et que surtout c'est depuis PHP que tu vas sécuriser la chose pleinement.
Qu'elle intérêt d'utiliser plusieurs bases de données ?
Car si c'est une question de données, c'est situé dans des tables.
@Fukotaku : Relire la question. Je ne parle pas de plusieurs bases de données. Il est question d'une seule, mais plusieurs connexions à différents utilisateurs de la base de donnée qui ont des permissions différentes.
Bonsoir.
Je ne comprends pas l'intérêt d'utiliser différents compte utilisateur pour ta base de données selon le rôle de l'utilisateur du site.
Les requêtes SQL sont faîtes du coté serveur et non du côté client.
Donc à moins que tu veuilles donner un accès à ta base de données, en dehors du site, comme par exemple avec une interface de SGBD comme PHPMyAdmin, je n'en voit aucunement l'intérêt.
Et je ne vois aucunement en quoi ton sujet peut concerner CakePHP ou n'importe quel autre Framework.
Ton sujet ne concerne que MySQL.
@Lartak Mon sujet conserne la sécurité contre les injections SQL de CakePHP3. S'il est préférable de restreindre l'accès public (non connecté) à la table «comptes» pour la connexion/creation de compte (INSERT, SELECT), pour ensuite utiliser une autre connexion avec plus de permissions pour la gestion du profil personnel ou contenu dans la table «profiles» et «contenus» (INSERT, UPDATE, SELECT), et une troisième connexion pour les modérateurs qui pourrait supprimer de l'information dans les tables sans pour autant supprimer/ajouter des tables (INSERT, SELECT, UPDATE,DELETE) ou si CakePHP3 offre suffisament de protection.
@Fukotaku L'intérêt c'est donner le moins de droit possible à la connexion à ceux qui n'ont pas besoin de toutes les options. Vous semblez plus ou moins me dire de laisser ROOT/«PASS» comme accès pour la connexion de tout le monde.
mais en faite comme la dit @Fukotaku il est ou l'intérêt?
si une personne a pas le droit de poster des donnée dans des formulaire et ne peut que lire et si tu protège tes formulaire avec du csrf ca suffit.
@Defy exactement, et puis pour les injections sql, tu vérifie les données qu'insert t'es utilisateur avec du preg_match
.
Mais normalement CakePHP gère lui même les parties injection sql et les clés csrf pour sécuriser tous ça.
Utiliser les techniques de sécurités offertes par cakephp3 n'est pas perdre son temps, un peu de respect pour ces fondateurs
@Defy Clé-CSRF n'empèche pas l'injection de code à partir de formulaire, juste l'envoi de formulaire d'une source autre que ton formulaire. Restraindre accès et permission, quel est l'intérêt : sécurité. Dans un réseau informatique, tu ne donnes pas accès au réseau et aux informations sensibles des autres à l'employé de centre d'appel et généralement le minimum de droit pour son poste pour qu'il ne puisse pas installer ou supprimer des logiciels.
@Kenor Enfin une réponse raisonnable, merci. Même si nombre de grosse boîte s'en servent, ils ont sans aucun doute des protections supplémentaires pour les serveurs et les bases de données, d'où ma question sur la sécurité avec CakePHP3.
@romses Prenez le temps de relire, sérieusement. Je n'ai pas dit que les techniques de sécurités offertes par CakePHP3 était perdre son temps. Je demandais si je perdais mon temps à faire trop de sécurité sur les connexions et les formulaires si CakePHP3 offre le degrée raisonnable de sécurité dès le départ qui empècherait les techniques basiques et intermédiaires de piratage.
Notez, j'ai fais un stage en milieu de conception Web, mais ils ne m'ont rien enseigner de particulièrement utile. J'ai remarqué néanmoins qu'il n'y avait pas plusieurs connexions (à part pour les informations de la BD production, la BD test et celui de développement) et des sécurités supplémentaires, mais ça semblait être contraire à ce qui m'avait été enseigné en réseau.
@Defy Bref que je n'ai pas trop à m'inquiété pour les connexions, qu'une seule suffit et que CakePHP3 est suffisamment sécuritaire qu'il n'y a pas réellement pratique plus sécuritaire au-dela que d'utiliser convenablement les outils disponibles avec le framework, ne pas utiliser PHPMyAdmin et ne pas utiliser ROOT comme connexion. Got it. Merci.
PhpMyAdmin n'est pas une faille en soit, mais c'est toujours une entrée supplémentaire que peuvent utiliser de potentiel hacker.
Du coup, effectivement, c'est préférable d'utiliser un Sequel Pro (d'autant que c'est tellement plus agréable à utiliser au quotidien ...).
Et puis, ça évite de devoir installer PMA dès que tu te créés un serveur (local notamment).
@Kenor J'utilise Oracle MySQL Workbench sur mon serveur test Scotch.box/Vagrant pour le moment. Je fais les diagrammes et il crée la commande SQL (ou je peux écrire les commandes ou modifier la BD directement), ou l'inverse transforme la structure de la BD en diagramme.