Discussion :

[Ingesys]

Bonjour,

Avant tout veuillez m'excuser si ce sujet a déjà été abordé dans le forum : après une recherche je n'ai trouvé que la référence d'un livre (Sécurité PHP 5 et MYSQL). J'ai malheureursement peu de temps à disposition pour m'intéresser à ces 300 pages (mais je le ferai cerrtianement par la suite).

Je ne suis pas développeur mais chef de projet, j'ai donc une vision globale des rapports infra/système & réseau/couche applicative.

Je me suis lancé un challenge personnel, à savoir développer un site ecommerce avec mes connaissances basées sur des années d'expérience en entreprise (+ des connaissances personnelles en scripting ou programmation (niveau neuneu)).

Mon propos est ici de me placer au niveau du code, et de la sécurité des appels de base mysql dans un environnement WAMP (ou Xamp sur Linux).

J'ai en effet (à ma grande surprise) réussi à développer une bonne partie du site après avoir consulté de nombreux tutos et de nombreux sites d'entraide (en me contentant des réponses apportées), mais au final, m'étant renseigné sur le risque d'injection SQL, je me vois contraint de revoir tout le code afin de le sécuriser.

Ma question est donc la suivante : Y a-t-il un moyen sûr ou une méthode sure de coder en structurant son code dans différents fichiers, par exemple script principal, appelant un script où sont définies les variables, un autre les fonctions (javascirpt par ex) et un autre les instructions SQL ? ou cela n'a-t-il aucune incidence ?

Deuxième question qui vient compléter la première : Afin d'éviter des intrusions, qu'est-ce qui ne doit pas circuler exactement entre un client et un serveur ? (plutôt que de décrire uniquement comment protéger l'accès aux valeurs des variables).

Je ne vais pas m'aventurer à mettre un bout de code ici car il s'agit de décrire une méthode globale.

J'ai pour ma part effectué des appels de bases classiques avec les instructions INSERT et SELECt essentiellement.

Je suis au courant pour les escapestring concernant l'appel des valeurs de la base avec $_post ou $_get, afin de protéger l'accès aux valeurs de la base, ainsi que des méthodes préparées.

Est-ce cependant suffisant ? Le risque d'injection ne vient-il pas plutôt (ou également) de la manière de coder son PHP ?

Si j'ai bien compris un hacker ne s'attaque pas au php (côté serveur -à moins d'une superfaille au niveau authentification), mais profite de la relation client/serveur pour introduire des données qui peuvent corrompre la base ou lancer des instructions sur la base pour accéder à ses valeurs.

Ce sont ces points que j'aimerais éclaircir.

Merci pour qui m'aura compris, qui aura le courage de faire un mini-tuto sur ces demandes de manière "fonctionnelle" et globale (sans rentrer dans des détails de code si possible) et désolé de la longueur du POST.

[Inazo]

Bonjour,

Alors ce n'est pas grave si le sujet à déjà été abordé cela fera une bonne piqure de rappel pour certain

Pour répondre à ta question d'une manière générale OUI mysql_real_escape_string te protègera des SQLi (Injection SQL) par contre sur le tutoriel que tu donne en exemple il y a une absurdité :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$requete = mysql_query("SELECT age FROM membres WHERE pseudo='$pseudo'");

L'utilisation de guillemet pour inclure la variable pseudo peut faire courrir un risque à l'application car PHP va interpréter le code $pseudo pour le jouer dans le code et cela peut être très dangereux. De plus l'utilisation de guillemet et fortement consommatrice de ressource car justement PHP recherche entre guillemet des éléments à exécuter en tant que code PHP...

Exemple ou mysql_real_escape_string est inefficace :

Si ma requete est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
$IsDo = mysql_query('SELECT * FROM toto WHERE id='.mysql_real_escape_string($_GET['donnelabmda']));

Si je met dans $_GET['donnelabmda'] ceci : "1 OR 2<>3" mysql_real_escape_string n’échappera aucun caractères et l'injection marchera sans soucis. Et je pourrais réaliser des requêtes voir sous requêtes complexe.

Donc toujours écrire comme ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
$IsDo = mysql_query('SELECT * FROM toto WHERE id="'.mysql_real_escape_string($_GET['donnelabmda']).'"');

Le but étant d'avoir toujours des guillemets qui entoure les valeurs donné à MySQL provenant de variable non sur (variable saisie par l’utilisateur ou pouvant être altéré tel que USER_AGENT)

Il vous est aussi possible d'utiliser la librairie PDO pour sécuriser vos requêtes SQL par contre attention une fois encore tout comme pour mysql_real_escape_string il faut l'utiliser de manière correct.

Si j'ai été trop vague ou que vous avez d'autres question n'hésitez surtout pas

Cordialement,

[ericd69]

salut,

vaste sujet...

y a pas de réponse simple, car rien n'est jamais vraiment sécurisé vu les différents angles d'attaque que tu peux avoir...
regarde les pauvres types de chez yahoo et leurs 450000 comptes piratés grâce à une faille sur un sous domaine...

tu ne peux qu'essayer de maximiser les bonnes pratiques mais par principe rien ne garantira jamais que suite à la mise à jour de telle ou telle couche logicielle, un jour une faille n'apparaitra pas (exemple ssl avec une des récente mise à jour java)... ça c'est la première faiblesse de toute technologie elle même dépendante d'autres comme sous-couches...

le 2ème point faible le plus commun, l'hébergement des services (mysql, apache, etc...) et la configuration (que celui qui possède l'hébergement) peut plus ou moins changer... exemples:

• un grand classique c'est l'injection de valeurs dans des variables php selon les réglages de php.ini
• le fait de mettre le chmod dans un répertoire à 777 pour de la manipulation de fichier sur LAMP... du coup une fois le fichier en place, il est exécutable

je te ferais même pas la liste des protocoles réseaux qui sont en soit une faille car conçus, originellement comme croyant celui qui répond et jamais modifier car trop de chose marche grâce à eux au niveau matériel... allé un petit exemple pour voir à quel point tu peux être attaqué sur des niveaux insoupçonnés...

enfin le grand classique selon le niveau des hacker, le sniffing permettant l'analyse des paquets échangés pour du reverse engineering et l'extraction de données, identifiant, mot de passe...

les attaques brutes de force, l'utilisation de rainbow table pour collisionner (casser) un mot de passe...

après, questions bonnes pratiques php(ou autres)/mysql(ou autres) sont simples en général:

• séparer le traitement sql du code php (comme on sépare le html du style)tant que faire ce peut:
  
  • utiliser un user ayant qu'un "grant execute" et des procédures stockées pour masquer ce qu'il y a dans la bd
  • ne JAMAIS utiliser de mot de passe et d'identifiant sql avec des droits sensibles dans le code, s'il y a la moindre chance qu'il soit récupéré ou lu par un hacker (surtout dans les applications de jeu ou avec des données sensible en java, c#, etc...) si la connexion est pensée comme devant se faire coté client(navigateur)... c'est d'ailleurs une grave erreur de conception
• les CMS sont souvent une vraie fausse bonne solution... ils sont souvent de véritables usines à gaz et bourrés de trous de sécurité (phpbb utilise encore md5 pour ses mots de passe par exemple)
• éviter de se donner des responsabilités dont c'est le rôle d'autres: les opérations bancaire, c'est le rôle des banques... chercher à leur prendre ce rôle, c'est juste s'exposer au attaques pour récupérer les identifiants bancaire qu'on voudrait stocker à des pseudo fins de "rendre le paiement plus simple et rapide"... y a qu'à voir le nombre de grandes enseigne qui passe un sale 1/4 d'heure en procès en dédommagement ensuite...

si on applique ça à php et mysql:

• oublier les connecteurs à mysql que sont mysql et mysqli... ils sont en voie d'abandon, utiliser PDO...
• ne jamais croire ce qui vient du client ($_GET,$_POST, etc...)
• limiter tant que faire ce peut les valeurs de type texte privilégier les valeur numériques...
• si tu récupères des valeurs venant du client, TOUJOURS les tester et garantir une valeur que tu contrôles, ne jamais les mettre telles qu'elles dans du sql, il faut que le type soit cohérent avec celui attendu...
• TOUJOURS échapper les chaines de caractères
• si tu peux utilise un user sql avec que "grant execute" et des procédures stockées... ça bloquera un certain nombre de possibilités d'injection supplémentaires
• pour les chaines de caractères, utiliser une regexp pour tester la présence de chose que tu veux interdire ou d'un format particulier (date par exemple)

PDO te permet de t'assurer que la valeur que tu passe est du bon type...

donc lis bien sa doc

[Inazo]

Je vais rajouter une tite remarque sinon le complément est bon :

pour les chaines de caractères, utiliser une regexp pour tester la présence de chose que tu veux interdire

Le plus souvent utilise plutôt des regex pour tester la présence de ce que tu attends.

Exemple classique :

Tu organise une fête dans Paris tu as invité 1000 personnes, est-il plus simple d'avoir la liste des 1000 invités et de contrôler les identités à l'entrée ? OU est-il plus simple d'avoir les millions d'identité qui n'ont pas le droit d'entrée ?

Ah oui et :

PDO te permet de t'assurer que la valeur que tu passe est du bon type...

Bien lire la documentation PDO pour l'utiliser comme il faut sinon rien ne sera protéger pour autant

Cordialement,

[ericd69]

OU le format voulu... tu peux chercher aussi bien ce que tu veux interdire ou autorisé ça dépend du contexte bien sur...

et certaines fonctions de php sont plus efficace qu'une regexp par exemple pour déterminer si tu es bien face à un email par exemple

le but est juste de s'assurer quand tu peux le faire de ce que tu rentres...

si tu es face à du texte libre ou du code que tu dois stocker, seul l'échappement sert ou le remplacement des caractères litigieux pour le stockage en bd...

[grunk]

Bonjour,

Ma question est donc la suivante : Y a-t-il un moyen sûr ou une méthode sure de coder en structurant son code dans différents fichiers, par exemple script principal, appelant un script où sont définies les variables, un autre les fonctions (javascirpt par ex) et un autre les instructions SQL ? ou cela n'a-t-il aucune incidence ?

Clairement non. L'organisation des scripts et du code n'a de seul intérêt que d'améliorer la maintenance / réutilisation du code et donc d'être plus productif.
Le "standard" actuel est de se baser sur le pattern MVC ou un de ses dérivés.

Deuxième question qui vient compléter la première : Afin d'éviter des intrusions, qu'est-ce qui ne doit pas circuler exactement entre un client et un serveur ? (plutôt que de décrire uniquement comment protéger l'accès aux valeurs des variables).

Tu peux faire circuler tout ce que tu veux , c'est la façon de le faire qui compte. Concrètement tout ce qui est considéré comme sensible doit circuler en https (donc crypté). Par exemple une identification d'utilisateur doit se faire en https , sinon les identifiants et mot de passe vont circuler en clair entre le poste client et le serveur. Idem pour la création de compte , le paiement , etc ...

J'ai pour ma part effectué des appels de bases classiques avec les instructions INSERT et SELECt essentiellement.

Je suis au courant pour les escapestring concernant l'appel des valeurs de la base avec $_post ou $_get, afin de protéger l'accès aux valeurs de la base, ainsi que des méthodes préparées.

Est-ce cependant suffisant ? Le risque d'injection ne vient-il pas plutôt (ou également) de la manière de coder son PHP ?

Pour les injections sql :
Ne jamais faire confiance aux données venant de l'utilisateur. Même une liste déroulante que tu as défini pourra être modifié.
Pour celà :
- Filtrage des données avec filter_var() et/ou filter_input()- Typage des données (faire un float_val() sur un prix par exemple)
- Requête préparées qui sont à l'heure actuelle la solution la plus sure.

Pour l'affichage :
Empécher toute execution de script camouflé dans des données coté client
- Echaper les données affichées via htmlentites() ou htmlspecilchars() afin d'éviter les faille xss.

Pour les formulaire :
- Utiliser un token pour se protéger des failles CSRF (cross site request forgery)

Pour conclure , quelques lectures utiles (c'est pas 300 pages )

Guide sur les authentification :
http://stackoverflow.com/questions/549/the-definitive-guide-to-forms-based-website-authentication/

Gérer les injection sql :
http://stackoverflow.com/questions/60174/best-way-to-prevent-sql-injection-in-php/

[Ingesys]

Bonjour à tous et merci pour vos réponses fournies.

Excusez ma réponse tardive mais j'ai été un peu surbooké ces temps-ci, et vous m'avez (à ma grande satisfaction) donné de la lecture supplémentaire, avec pas mal de liens à consulter...(lus au coup par coup ces derniers jours).

Je me dois donc ici de faire une réponse collégiale, car répondre à chacun d'entre vous serait trop long.

Commençons par les risques liés au réseau et à l'authentification : mon projet sera hébergé par un hébergeur de qualité (j'ai mes contacts ). Je lui fais donc confiance pour me fournir un environnement sécurisé (exit les failles du cache ARP, etc...), que ce soit au niveau infra, réseau ou système.

Concernant la partie financière. Effectivement, c'est le travail des banques et je sais heureusement par mes fonctions passées que des organismes font cela très bien. J'ajoute d'ailleurs qu'au delà du risque mentionné sur le vol de données bancaires pour celui qui s'aventurerait à jouer le rôle des banques, il se verrait encourir une responsabilité au niveau juridique qui pourrait avoir de graves conséquences sur l'avenir de sa société.

Concernant le hashage de données, j'ai lu personnellement que le MD5 était obsolète, et qu'il vaut mieux faire du Sha1 (merci de bien vouloir confirmer). Mon site aura une partie User et une interface Admin (comme tout bon site e-commerce). La partie admin sera sécurisée en SSL. Par contre, à lire grunk il faudrait si j'ai bien compris que le site soit intégralement en https....euh... obligé ? (ça coute bonbon tout ça...)

Pour finir, j'ai zappé pas mal de trucs et je m'en excuse (j'ai bien intégré quoi qu'il en soit l'usage des guillemets, et bien sûr que l'utilisateur ne sera pas root), mais la soluce finale serait si j'ai bien compris d'utiliser un framework : ça éviterait les mauvaises pratiques en matière de sécurité au niveau code/base, et ça permettrait de structurer le code ou de le moduler, afin de s'en resservir pour le même projet et d'alléger les charges serveurs, ou carrément pour développer par la suite d'autres projets similaires.

J'ai parcouru (notamment sur votre site) des messages d'utilisateurs qui comparaient les framewroks (mais c'est très subjectif), et je n'arrive pas à me décider : j'hésite entre Cake PHP, Symphony, ou Yii qui pas l'air pas mal pour ce que je dois faire. Les niveaux de sécurité ont l'air différents de l'un à l'autre (certains seulement verrouillent les failles CSRF).

Sur l'interface d'admin j'ai néanmoins deux questions :

Que pensez-vous du recours à un webauth ?
Ne vaut-il pas mieux faire une table spéciale admin avec identifiant unique, que de mettre l'admin dans la table users ? ou c'est inutile ?

Pour la gestion des tables mySQL, que pensez-vous de dbforge Studio for mysql de Devart ? L'avez-vous utilisé ? (j'ai vu la pub sur un des liens fournis).

Merci pour vos réponses.

J'essaierai d'être plus rapide pour répondre cette fois-ci. :-)

[ascito]

pas une remarque pour PDO ( j'ai lu en travers ) ?

avoir un endroit ou toutes les transactions bdd vs clients sont OK sur un serveur donné avec login mdp

a l’époque, les plus grands pirates étaient des employé des entreprises ???

nan, faut pas te faire de bile, les personnes qui peuvent te pirater :

ton provider : ( des personnes bossant chez eux pas tres reglos )
ton ami : il vient chez toi et se sert de ton ordi
ton voisin : po de bol c'est un pirate, il capte tes mots de passe par http
ton client : ??? po sur qu'il ai que çà à faire

[ericd69]

si si j'en ai parlé

tu as été trop de travers...

[Inazo]

Bonjour,

Ceci n'est pas vrai :

mais la soluce finale serait si j'ai bien compris d'utiliser un framework : ça éviterait les mauvaises pratiques en matière de sécurité au niveau code/base

Utiliser un framework ne protège pas des mauvaise pratiques de code et de sécurité. Encore faut-il utiliser ces outils de manière correct tout comme pour ma remarque sur PDO, certain l'utilise en disant "j'ai PDO je risque rien !" alors qu'il laisse des failles SQL béante du fait de la mauvaise utilisation des fonctions.

La réciproque est vrais pour les CMS ce n'est pas parce que vous utilisez un CMS que votre site/application est une passoire.

HTTPS partout si vous avez les moyens why not... Après il y a SSL et SSL ceux sans assurance en cas de problème ou avec des assurances ridicule et les certificats capable de couvrir plus de 500k € d'assurances.

Cordialement,

[grunk]

Concernant le hashage de données, j'ai lu personnellement que le MD5 était obsolète, et qu'il vaut mieux faire du Sha1 (merci de bien vouloir confirmer).

Le md5 est obsolète c'est certain. Le SHA à tendance à être déprécié aussi à cause des nombreuses table de correspondance (rainbowtable) disponible. Il est moins facile à bruteforcer, mais pas forcément idéal.

La mode en ce moment c'est bcrypt. Un algo que l'on peux faire évoluer dans le temps avec un simple paramètre au fur et à mesure que les machines deviennent plus puissante.
Il à la particularité d'être très lent (comparé aux autres) et donc d'être très difficile à brute forcer. De plus chaque mot de passe est salé avec un sel aléatoire et un même mot de passe ne donnera pas 2x le même hash , du coup ça exclu les tables de comparaison.
Un exemple d'implémentation avec Blowfish : https://github.com/grunk/Pry/blob/ma...rypt.class.php

Une lib de référence dans le domaine en ce moment est phpass (ouais c'est pas glorieux comme nom ^^ )

Par contre, à lire grunk il faudrait si j'ai bien compris que le site soit intégralement en https....euh... obligé ? (ça coute bonbon tout ça...)

J'ai pas dis tout le site , j'ai dis les données sensibles
Que quelqu'un puisse intercepter les données du panier n'a aucune espèce d'importance , par contre les identifiants (à l'authentification) ça c'est génant.
Le plus simple est de regarder comment la problématique est gérée par les gros site de ecommerce.

Un certificats ssl c'est valable pour tout ton domaine , donc une page ou un site c'est pareil. Ça te coûtera juste un peu plus cher en bande passante si jamais tu la paye.

mais la soluce finale serait si j'ai bien compris d'utiliser un framework : [...] et d'alléger les charges serveurs.

Un framework ça fait tout ce que tu veux sauf alléger la charge serveur. Certain du genre de symfony sont même incapable de faire tourner un site en production sans un minimum de cache d'opcode. Une fois configuré correctement ils peuvent cependant être performants.

Ne vaut-il pas mieux faire une table spéciale admin avec identifiant unique, que de mettre l'admin dans la table users ? ou c'est inutile ?

En général on découple complètement le backoffice (admin) du reste. Ainsi les utilisateurs , les sessions ... sont complètement différents. Il faut considérer l'admin comme un application à part. C'est pour moi le plus sur.

Pour la gestion des tables mySQL, que pensez-vous de dbforge Studio for mysql de Devart ? L'avez-vous utilisé ? (j'ai vu la pub sur un des liens fournis).

Mysql fournit MysqlWorkbench qui marche très bien

[redoran]

une fois connecté on est devant ce que j'appel les dents de la mer ou fredy..
y'a toujours de nouveaux risques donc sécurité et menace évolues en parallèles (maitrise de risque).
donc selon certaines publication on démontré que les motifs d'agressions sont dues:

1. pour le gain (lucratif).
2. fraude.

donc comment définir un niveau de sécurité optimal ?
là la sécurité doit étre pensée durant tous le cycle de développement et non a la fin du cycle.
en générale la sécurité passe :
développeur N° 1 !!!!!!! ( cahier de charge , missions partagées.... , formation au développement sécurisé)
l’hébergeur ( moyen humain est matériel).
serveur ( soft + présence d'autres applications augmentant le risque).
application web:
gestion de l'authentification ( comment?).
les injections (bdd , LDAP , cross site scripting).....
tous cela envoi vers les bonnes pratiques !!!!!! (proactive ou par prévention...)
suivre les nouvelles du piratage...
un avis d'un expert....
donc la liste est langue.....
je ne c'est pas s'il existe un référentiel sur la sécurité dans le forum !!!

[Ingesys]

Bonjour,

Merci pour le lien sur Workbench grunk ! Je ne connaissais pas...

Je précise naturellement que j'ai simplifié la chose sur les rapports Front / Back. J'ai un peu trop la tête dans le guidon au niveau code, pour m'être interrogé sur la structure de mon site.

En fait, mon challenge perso c'était de me prouver que je pouvais coder en PHP / MySql pour obtenir ce que je voulais. Donc, j'ai un peu mis la charrue avant les boeufs...

J'en profite pour apporter ici ma petite contribution :

La structure au niveau environnement idéale pour un site e-commerce c'est DEV/ PPRD / PRD (développement, pré-production, production).

Seules les PPRD et PRD ont chacun un Front et un Back, ce sont en général deux copies identiques, et on fonctionne par réplication -on pousse donc de la DEV vers la PPRD ce qui évite de pousser n'importe quoi en PROD, lors de modifications apportées au site (que ce soit sur l'aspect du site ou sur le contenu), ce qui peut faire planter le site (si, si c'est déjà arrivé). Dans ce cas là, les accès Admin ne se font qu'en PPRD. Seul l'hébergeur a des accès en PROD. Quant à la DEV c'est ici mon PC en localhost (ça c'est réglé).

Le serveur Front comporte Serveur Apache, Php, MysqL, et les applications Web. Le serveur de Back comporte les données de ces applications et la base SQL à proprement parlé (ça évite pas les injections, mais ça évite de se faire pomper la base "en dur").

Maintenant je suis pas Crésus non plus, et je vais évidemment me contenter d'un structure Front-Back simple. A savoir s'il ne faut pas plusieurs instances de MySQL ou un MYSQL en Front et un en Back, là j'avoue que je sèche. Tout dépend de se qu’accepte le fichier My.ini comme config (datadir1, datadir2,...) ou un My1.ini, My2.ini. Honnêtement j'ai jamais essayé.

Il faut donc à mon avis deux bases séparées avec des tables communes (produits, ventes, notamment). Et on fonctionne par réplication de tables communes du Back vers le Front par des simples Cron ou MAJ manuelles.

Bref...tout ça c'est de la sauce hébergeur et je compte sur leur savoir pour me pondre un truc au mieux au niveau sécurité.

Pour en revenir au Framework, à ce que j'en ai lu, pour les plus connus et les plus récents d'entre eux, normalement c'est verrouillé au niveau attaques en tout genre, et ça permet de pas trop mettre le nez dans le code. Après, à vous entendre, si c'est pour se taper des vérifs à tout va, alors ça vaut peut-être pas le coup.

Pour le SSL, oui, c'est affilié à un nom de domaine. Maintenant rien n'empêche une restriction à l'usage de la partie Admin...mais bon pourquoi se priver dans ce cas...

Merci pour vos précisions sur MySQL. Encore une fois, j'ai toujours vus ça globalement.

[ericd69]

juste un petit retour sur la sécurité...

on en a longuement parlé dans un post dédié ici même... résumons un peu...
2 techniques concerne les mots de passe ou les données sensibles:

• le cryptage, réversible, utilisant des fonctions engendrant une chaine de caractère dont la longueur dépend de la force du cryptage voulue (qui est limité pour l'usage privé dans la plupart des pays)
• le hashage, irréversible, qui consiste à générer une chaine de taille fixe dépendant de la fonction choisie

selon la politique de génération des mots de passe, tu peux choisir l'un ou l'autre:

• le hashage est souvent utilisé pour gérer des données utilisateurs où le principe est que c'est à lui de décider de l'identifiant et du mot de passe. l'administrateur ou autres utilisateurs avec pouvoir ne peuvent savoir ainsi ce qui a été mis, limitant le risque de vol interne (sachant que les gens utilisent souvent le même identifiant et mot de passe pour diverses activités)...
• le cryptage lui sert plus dans une politique centralisée de gestion du personnel et de ses accès (intranet d'administration, entreprises)

chacunes de ces techniques a ses défauts aussi:

• comme un hash est le même pour différentes valeurs , il suffit d'en trouver une qui le génèrera (collision)... c'est le but des rain bow table qui sont générer par des heuristique pour minimiser le temps nécessaire par rapport à une simple attaque brute de force...
• le cryptage étant réversible les faille sont lié aux risques internes de fuites et à l'utilisation de cryptages trop faibles par rapport à ce qui est utiliser pour le casser

les 2 techniques représentent un cout d'exécution sur le cryptage...

l'utilisation de ssl se discute en fonction du cout financier qu'il représente (le certificat) sur l'hébergement et de la nécessité réelle de combattre les techniques de sniffing qui intercepteraient les données échangées entre le client et le serveur... en interne, pour l'administration tu peux parfois utiliser un certificat collectif sur certains mutualisés, selon la formule choisie chez l'hébergeur (ovh le propose sur les hébergements pros et supérieurs)... après en local tu as des générateur de certificats gratuits...

la séparation des serveurs est un surcout inutile à mon avis hormis pour des infrastructures à SLA très élevé et pour des performances extrêmes mais avec tout dans une baie unique (pour load balancing, etc...) sinon tu y perds sur le bridage de BP...

pour les frameworks, c'est comme pdo ou autres... il faut toujours bien lire les docs...

après comme je te le disais, la vraie protection pour un sgbd, c'est de séparer au maximum le code sql du reste...
et de n'utiliser qu'un utilisateur sql qui n'a que "grant execute" comme droit avec des appels à des procédures...
c'est le principe utilisé pour les applications sensibles (banque, jeux online, etc..)
le seul gros défaut de leur implémentation par mysql c'est qu'elles sont re-compilées par à la première utilisation lors de chaque connexion au lieu de lors de leur création... il en résulte une accélération de l'exécution seulement si on a des appels multiples à une même procédure lors d'une session (connexion)

[Ingesys]

Bonjour à tous,

Merci pour vos précieux renseignements.

Je me demandais simplement si quelqu'un avait la réponse au niveau config Mysql (où dois-je ouvrir un nouveau Post ?).

Pour récapituler, si je fais deux bases distinctes, j'ai bien compris que c'est au niveau du demandeur de la requête que la bonne base sera interrogée (user -> Base users ; admin -> Base admin), mais au niveau config Mysql comment ça se passe ? Les instances sont automatiques ?

Merci pour qui a la réponse, car si je suis obligé de développer deux bases distinctes autant bien faire les choses dès le départ, et ce serait bête ensuite de me retrouver bloqué...

[ericd69]

si c'est sur la même machine la communication avec plusieurs bd c'est juste une question de droit de l'utilisateur qui y accède...

si tu as des bd distribuées sur plusieurs machines... tu peux utiliser le moteur federate pour déclarer une table virtuelle dans l'une des bd qui pointe sur la table distante dans une autre...

[ascito]

prenons le cas de ton serveur dédiée, ou tu as l'accès a httpd.conf ou | et a phpmyadmin

tu peu créer des virtualHost, chaque virtualHost pourra avoir une base de donnée.

le manager principal de ton serveur dédiée est root, et il a un mot de passe, donc celui du super Admin BDD..

dans chaque bdd, de chaque virtualHost tu doit configurer des utilisateurs avec login et mot de passe, ainsi que les permissions, car par default, c'est peu être ceux de ton Super Admin...

Tu ne pourra pas aller plus loin en terme de sécurité ( bdd , login , mdp , permission ), au premier niveau

C'est déjà ce qu'il faut faire

Il faut donc à mon avis deux bases séparées avec des tables communes (produits, ventes, notamment). Et on fonctionne par réplication de tables communes du Back vers le Front par des simples Cron ou MAJ manuelles.

ca c'est une vue gestion projet, mais c'est pas forcement crédible en dev, et en prod.... a moins que tu veuille alourdir très fortement ta bdd...

Je suis pas sur, mais pourquoi répliquer une bdd de 100000 lignes, quand c'est juste une colonne d'ajouté sur une table ( voit tu la maintenance qui en découle, pour les dev ) . Donc, bien faire son merise de départ, aussi..


La je propose , des instances de bases très légères, avec une réflexion sur l’interaction des tables entre table vers les scripts, mais jamais une bdd cliente lourde ou tu réplique tout a chaque fois, C CONTRE LA PENSE LOGIQUE


les modules s'ajoutent, les contenus doivent être unique quelque soit la version de ton framwork, ( ton client va pas apprécier de refaire ses contenus ) donc grosse erreur de ta part si tu pense qu'il est bon de répliquer les tables dans des nouvelles bdd ( maintenance Impossible, sauf si tu prévois les stades , import, -> test new framwork - > validation -> import base a jour -> mise en ligne ) ; et encore une fois je ne conçoit pas que ce soit CREDIBLE, si tu fais ca toutes les semaines comme courant chez les chef de projet !!!!

C'est une faute de conception, voila

[ericd69]

franchement, je suis d'accord avec ascito...

quelle est vraiment l'utilité de faire ça?

que tu utilises une modélisation comme merise ou juste la simple logique... y a peu d'activités qui nécessitent d'avoir de lourd système de réplication...

trouve moi un seul cms de e-commerce qui le fasse???

en gros, pourquoi une séparation de bd voir de machine pour le back et front?
justification?
cout?...

ça devrait rester dans tes compétences actuelles de répondre vu ton boulot...

comprendre l'adéquation entre le but et les moyens

rien que pour dimensionner l'hébergement, choisir les bonnes technologies... rien que ça va tout de suite limiter tes possibilités clairement...

au moins, tu vas finalement apprendre plus que tu le pensais de ce projet... et te faire progresser même en tant que chef de projet...

ça devrait être un challenge à proposer régulièrement à tout ceux qui font ton boulot, pour encore mieux comprendre parfois les devs et les contraintes...

une bonne auto formation

[Ingesys]

Ben, vous êtes pas loin de la vérité.

Cette démarche que j'entreprends a un double intérêt, c'est un challenge perso pour essayer de faire un biz, et ça me sert aussi à avoir la vision d'un développeur sur de tels projets.

J'ai bien conscience en tant que chef de projet (pas uniquement web) que 80% du projet, c'est du code, que ce soit pour une appli ou du web (certains ont tendance à l'oublier).

C'est certainement là où pêchent les chefs de projet sur de nombreux projets.

Après, je vous renvoie la balle, côté dev, car autant je suis d'accord pour dire qu'un chef de projet doit impérativement maîtriser un minimum le boulot du dev, mais de l'autre côté ce qui caractérise un bon dev, c'est sa manière de coder : le code doit être le plus léger possible, afin de limiter les ressources et gagner en perf, et surtout sécurisé : ce que j'ai vu à gauche et à droite sur le Net fait assez froid dans le dos à ce niveau...

Quant à la séparation du Back et du Front, c'est systématique en TGE (vous me direz ils ont les moyens) et pas forcément sur de gros projets.

Je faisais en plus qu'aller dans le sens de Grunk qui me disait la même chose, et je l'ai expérimenté sur du Web par le passé en tant que Coordinateur technique (c'était pas moi le chef de projet ). Je l'ai ensuite revu sur du Web (où je faisais de l'intégration).

Les réplications se font la nuit, et sont programmées, c'est une manière de fonctionner comme une autre.

Encore une fois, avoir un unique serveur avec tout dessus, ça coûte moins cher, mais c'est dangereux à plusieurs niveaux, et notamment lors de changements apportés au site. Et dans ce cas une restauration de la base engendre une rupture de prod et est bien plus gourmande en ressources.

Donc puisqu'on parle sécurité, il faut en tenir compte.

Il faut également comprendre que le Back office en e-commerce ne se résume pas à un simple serveur ni à une simple fonction : la gestion des stock et la partie logistique ou livraison est en général effectuée par des intervenants différents quand il ne sont pas extérieurs.

C'est aussi une des raisons de la séparation Front et Back : permettre un environnement sécurisé en se prémunissant des users, mais aussi en renforçant la sécurité des intervenants.

Quant aux web agency qui développent le site même s'ils sont ordonnateurs de la structure de la base, ils n'ont aucunement accès au Back, et se connectent au Front par Webauth en général.

Voilà la structure idéale au niveau sécurité, côté infra et intégration.

Vous devez savoir d'ailleurs en tant que développeurs que l'on ne confie pas la totalité du code à une seule personne (ou à une seule équipe, en fonction de la taille du projet). C'est le même principe côté infra, intégration et infogérance : à chacun sa tâche.

Je vous remercie en tout cas pour vos conseils que je ne manquerai pas d'appliquer.

[ericd69]

oui je sais, t'inquiète pas

mais après comme tout méthodologie, c'est pas parce que ça existe que c'est adapté à tout...

regarde la polémique autour du scrum...

• bien employé ça donne donne des couts de production et une réactivité la plus efficace possible...
• mal employé sous couvert d'une gestion de projet simplifié, entraine une conduite de celui-ci négligente car sans réels objectifs minimaux...et parfois coule le projet du coup...

le problème comme toujours c'est l'adaptation, la souplesse... et le bon dimensionnement... une cohérence... ne pas utiliser des techniques comme des dogmes...

la réplication peut-être fait de moult manière même une copie de l'activité journalière/hebdo/mensuelle sur support amovible...

la gestion des risques est, en effet, un problème majeur... mais là encore ça a un cout que tout le monde ne peut ou n'est pas prêt à supporter... et y a là encore bien des compromis

pour aller dans ton sens sur de bonnes choses mal utilisées se révélant contre productive:
quand un langage n'impose pas d'avoir une entité (classe ou équivalent) par fichier, il vaut mieux bien réfléchir à ne pas appliquer ça à lettre, surtout pour des langages interprétés... car en sous-jacent, tu démultiplie les lectures de fichiers et ça risque de grever les performances surtout pour lire des trucs de moins d'1ko...

bref c'est clair que c'est un travail d'équipe ou chacun doit apporter sa pierre et des connaissance que l'autre n'a pas forcément