Discussion :

[Coeur De Roses]

Bonjour à tous,

J'ai cru comprendre que par les dires de certaines personnes qu'il ne faut pas stocker les clés de chiffrement sur la même base de données ou le même serveur, savez vous comment faire s'il vous plaît ? Je vais utiliser sodium.

[grunk]

Effectivement en règle général c'est déconseillé. Puisque si le serveur vient à être compromis , si les données son cryptées mais que la clé est facilement accessible ca ne sert à rien.

La problématique étant que si on stock la clé ailleurs , comment sécuriser la connexion qui permet de récupérer la clé ? C'est un peu le serpent qui se mort la queue.

* L'idéal, c'est de ne pas avoir la totalité de la clé. Par exemple une partie de la clé est commune à tous les utilisateurs et elle est ensuite complétée par une partie que seule l'utilisateur connais. L'inconvénient c'est que tu n'as toi même pas accès aux données.
* La solution suivante c'est d'utiliser les capacités matérielles. Par exemple les modules TPM pour stocker la clé. Ce n'est, à ma connaissance, pas accessible en PHP
* On peut aussi imaginer une clé découpée en plusieurs parties. Une partie dans le code PHP , une partie dans un fichier hors racine web , une partie dans la bdd. C'est légèrement mieux que d'avoir la clé à un unique endroit.
* La dernière solution , stocker la clé dans un fichier en dehors de la racine web. idéalement dans protégée par un mot de passe.

Un post intéressant sur le sujet : https://security.stackexchange.com/a/48085

[Coeur De Roses]

Merci de ton aide Grunk, je ne m'y connais pas en sécurité informatique donc c'est galère.

[ABCIWEB]

Oui les deux dernières solutions proposées par grunk sont la plupart du temps assez simples à mettre en place. Mais bon à part cela si tu n'y connais rien en sécurité informatique, tu peux aussi avoir des trous de sécurité dans ton code. L'oswap permet d'en apprendre un peu plus. Et puis évidemment fais gérer ton serveur par des professionnels (ou prend un mutualisé chez un hébergeur professionnel), la gestion serveur est un métier qui ne s'improvise pas.

[Coeur De Roses]

Merci Abciweb. J'ai pris un hébergement web mutualisé chez Hostinger. Je m'étais rendu compte que je comptais faire des trucs qu'il est mieux de laisser à une entreprise de faire, du coup Hostinger là, étant donné à quel point je suis nul en sécurité.

J'ai un administrateur réseau dans ma team, pas encore dispo pour l'instant. A par ça actuellement il y'a que moi sur le backend. J'ai aussi vue qu'une des autres solutions était de mettre la base de données sur un serveur différent du serveur hébergeant le site web https://security.stackexchange.com/q...encryption-key dans le point 5 de la réponse donné par une personne.

[ABCIWEB]

J'ai aussi vue qu'une des autres solutions était de mettre la base de données sur un serveur différent du serveur hébergeant le site web.

Ce n'est pas toujours possible, notamment pour les serveurs mutualisés type OVH, et pour des raisons de sécurité précisément, ils peuvent ainsi mieux maîtriser tout le processus de connexion au serveur de base de données.

Après dans la pratique les serveurs de base de données gérés par les hébergeurs (dans les hébergements mutualisés) se font très rarement pirater directement. Ils ont des pros qui se renseignent en permanence sur les nouvelles formes d'attaque, des processus de surveillance automatisés, des sauvegardes automatiques sur différents serveurs etc. La plupart du temps les pirates exploitent des failles dans le code des fichiers, processus d'authentification, injection sql etc. C'est pour cette raison que les sites Wordpress sont souvent visés car le code est open source et il suffit donc d'utiliser un module qui a une faille et qui n'est pas (ou plus) mis à jour pour se faire pirater son site.

Pour dire que si tu es développeur ton principal travail est la sécurité du code (injections sql... cf oswap), les contrôles de données côté serveur, token dans les formulaires, le process d'authentification si tu as un espace administrateur, utilisation de https et non pas http, etc. Si tu ne connais pas bien tous les aspects tu peux aussi utiliser un framework, symfony (mais long à maîtriser) ou autre.

[Coeur De Roses]

Merci Abciweb.

Pour l'instant je vais me débrouiller avec ce que vous m'avez dit, ce que j'apprends de mon côté. Je vais attendre plus tard que quelqu'un qui rejoigne l'équipe et qui s'y connait mieux que moi, s'occupe de la partie sécurité. C'est sûr que ce que je vais faire, ça sera perfectible par quelqu'un qui s'y connait mieux. Pour la partie injection sql c'est bon j'ai géré avec les requêtes préparées concernant les entrées utilisateurs.

[ABCIWEB]

Pour la partie injection sql c'est bon j'ai géré avec les requêtes préparées concernant les entrées utilisateurs.

Oui concernant les entrées utilisateurs (formulaires) les requêtes préparées sont "obligatoires" mais n'oublies pas non plus les token qui permettent de s'assurer que les données ont bien été envoyées depuis le formulaire, et contrôle le plus possible les données côté serveur. Ainsi tu pars sur de bonnes bases.

Après il faudra par exemple aussi sécuriser la gestion des sessions (session.use_strict_mode, session.sid_length, session.sid_bits_per_character...) et des cookies (options "secure", "httponly" et "samesite") mais cela peut généralement se faire en amont du code donc tu n'auras pas tous tes formulaires à modifier.

[Coeur De Roses]

Merci, la sécurité de session là et des cookies, j'y avais pas penser, je sais aussi que je vais devoir faire gaffe aux failles Xss.

Par contre pour les cookies j'en ai crée aucun dans le code php et nulle part ailleurs, mais j'ai remarquer la création de cookies automatiques un "Uniquement les connexions au même site" et le PHPSESSID qui est supprimé lorsqu'on quitte la session me semble logique. Je m'en serais bien passé pour la conformié RGPD, du travail en moins que ça aurait fait ,mais j'ai pas le choix, va falloir peut être que je fasse un truc dessus par précaution.

Le truc des token de formulaires je connaissais pas aussi.

[ABCIWEB]

Salut,

Les token sont utilisés pour lutter contre les failles CSRF, de même que l'option session.cookie_samesite pour la configuration du cookie de session, et l'option samesite pour les autres cookies.

Concernant les failles XSS, il s'agit de contrôler et de se protéger le plus possible des entrées utilisateur. Le contrôle peut être facilité par la définition des variables utilisateur attendues dans ton code. Par exemple il est très facile de contrôler la validité d'une valeur numérique, c'est moins facile pour les chaines de caractères. Pour la protection côté php on utilise impérativement "htmlspecialchars" pour afficher des variables dans le html, pour les cookies il y a aussi l'option "httponly" qui interdit l'interaction avec javascript, l'option "secure" qui impose l'utilisation de https.

Il n'est pas impossible que tu soit amené à utiliser des cookies internes (autre que le cookie de session) lors de l'évolution de ton site, et si tu utilises un serveur d'évaluation local sur ton pc tu remarqueras que certaines options ne sont pas compatibles avec le serveur de production distant, notamment l'option "secure". Dans ce cas tu as tout intérêt de prévoir un bout de code dans l'initialisation des pages Php qui distingue une connexion locale d'une connexion distante pour créer une constante qui pourra servir à définir l'option "secure" (entre autre) pour l'envoi des cookies. C'est pus simple si on le prévoit dès le début.

Enfin concernant la loi RGPD les cookies de session ne sont pas concernés. En fait c'est l'utilisation que tu fais des cookies qui est réglementée. Tous les cookies qui n'enregistrent pas de données utilisateur qui seront exploitées à des fins commerciales ou transmises à des partenaires (google etc.) ne sont pas concernés. Grosso modo tous les cookies qui ne sont pas exploités pour enregistrer des informations personnelles sur un serveur ne sont pas concernés.

Par exemple, ce module wysiwyg dédié à la création d'un filigrane sur image dans le contexte d'un upload, utilise un cookie pour la gestion des presets, mais les données de ce cookie ne sont enregistrées sur aucun serveur, ce n'est pas un cookie traceur.

Par contre si tu inclues des script externes, genre bandeau de pub ou statistiques google, ou si tu utilises des cookies pour récupérer et stocker des données personnelles, la RGPD stipule que le consentement de l'utilisateur est indispensable.

[Coeur De Roses]

Merci encore. Je vais me servir de ces réponses pour peut être apporter des choses auxquelles j'avais pas du tout penser avant concernant la sécurité. C'est compris pour le RGPD, je crois que côté cookie j'ai donc rien à faire, excepté les cookies de sessions, on a rien d'autres en cookie / pas de code en rapport, je ne compte pas en utiliser pour le moment, j'ignore si ce sera le cas plus tard.

[Coeur De Roses]

Autre question svp.

Imaginons les informations de candidat dans une table de candidats, une ligne = un candidat, nom,prenom, dîplomes, compétences etc...
Preferez vous faire une clé de chiffrement pour toute la ligne ou bien chaque cellule devrait avoir sa propre clé de chiffrement ?

J'imagine que les cellule avec chacune sa propre clé est plus sûr, bien que les performances sont peut être à discuter.

[grunk]

Perso j'ai jamais vu une clé par ligne encore moins par cellules.

La plus part du temps c'est une clé pour l'application.Si on veux vraiment compartimenter on peut pousser à une clé par utilisateur mais plus ca n'a pas d'intérêt a part se compliquer la vie.

[Coeur De Roses]

Merci Grunk. Désolé si je multiplie les questions les gars.

Hm, disons que le RGPD... me fait être un petit peu aux aguets. Ca m'a effleuré l'esprit d'aller jusqu'à coder de manière à avoir une clé pour une cellule, mais j'ai un peu pris conscience de ce que tu m'avais dis dans un autre poste, que le chiffrement peut poser problème pour la recherche en bdd. Quand tu dis chiffrement au niveau de l'application, c'est à dire une seule clé pour un site web ou une clé pour une base de données ?

J'avoue que j'ai pas envie de me casser la tête non plus donc si déja je me dis que j'utilise une clé de chiffrement pour une table au lieu de chiffrer chaque ligne, je préfère. Donc serait-il possible de faire une clé de chiffrement pour une table ?

[grunk]

Tout est possible mais une clé par table me semble encore une fois excessif sauf peut être si on y stock des données extrêmement sensible.
Et puis généralement il n'ya que quelques champs dans toutes une applications qui ont réellement besoin d'être chiffrée, le reste c'est souvent que des données technique.

Je ne sais pas ce que demande le RGPD une clé pour la BDD entière me semble suffisant dans la grande majorité des cas.

[Coeur De Roses]

Merci,

Juste en sachant ça, ça me fait avancer. Je vais finalement laisser le fait de placer la clé sur un autre serveur, car franchement trop de complications c'est finalement moins évident que ce que je croyais, j'ai essayé chez un hebergeur, ça n'a pas été possible après avoir parler au téléphone ou soit faut si connaître en administration serveur dans un autre cas j'ai lâché l'affaire.

Je m'en remets à la solution de stocker la clé dans un fichier et mettre un mot de passe mais même ça je galère à trouver comment faire. Même ça bien que comme dit ABCIWEB, c'est plus abordable, je ne sais pas faire lol.

Sur le site de la CNIL https://www.cnil.fr/fr/securite-chif...rite-ou-signer "Protéger les clés secrètes, au minimum par la mise en œuvre de droits d’accès restrictifs et d’un mot de passe sûr." Mais j'ai beau chercher sur le web, je ne trouve nulle part comment faire. Où je regarde effectivement des site où ça parle de chiffrement de stockage de clé, mais j'ai pas vraiment de marche à suivre dans ma situation. Développeur ( du dimanche je le rappel ) qui se sert d'un hebergeur pour stocker son site web mais ne sait pas comment faire pour stocker les clés.

Je n'ai d'autre choix que... de vous demander à nouveau de l'aide hahahahaha s'il vous plaît. Oui je sais normalement on est supposé se casser la tête et pas attendre que tout nous tombe du ciel.

Et puis ensuite même en supposant que je met le mot de passe, est ce que je dois aussi saisir ce mot de passe dans le code pour accéder aux fichier, si oui comment svp ou est ce que le mot de passe donne une restriction à quelqu'un qui souhaite ouvrir le fichier juste en cliquant sur le fichier comme on le fait pour n'importe quel fichier qu'on souhaite juste éxecuter ou ouvrir.

Sur le tableau de bord de mon hébergeur, il y'a une partie où c'est écrit "Répertoires protégés par mot de passe" puis "Définissez un mot de passe pour limiter l'accès à votre site Web (ou à certaines sections)." Est ce que c'est ça ? Ou modifier les permissions de fichiers / dossier, éxecution, lecture et modification ?

Mon site est dans un hébergement web mutualisé. J'utilise le langage php.

Faire en sorte que le code PHP puisse accéder à quelque chose en dehors de la racine web ? Donc ce qui signifie qu'on est plus du tout dans le dosser qui contient les dossiers et fichiers du site.

Je souhaite savoir vraiment toutes les étapes s'il vous plaît .

Edit: possible qu'Infomaniak puisse me faire ce que je veux pour les 2 serveurs, 1 qui garder le site et une bdd et l'autre avec juste une bdd pour séparer données chiffrés et clés, ils m'ont confirmé que oui, j'attends de voir comment ça va se passer niveau paiement et hébergement. Désolé les gars je sais que j'ai beaucoup écrit, mais quand on est gros naze voilà ce que ça donne mdr.

[ABCIWEB]

Salut,

Connectes-toi à ton serveur avec un client FTP comme FileZillla, en utilisant de préférence le port 22 pour bénéficier du SFTP (secure ftp). Tu verras un dossier www qui est accessible depuis le net. Le principe est de créer un autre dossier qui lui ne sera pas accessible depuis le net mais uniquement par php. Donc cliques droit sur le dossier parent pour créer un autre dossier à partir du menu contextuel. Tu remarqueras au passage que l'on peut aussi définir les droits des fichiers et dossiers depuis ce menu contextuel.

Supposons que tu aies créé un dossier nommé 'CLES' (qui sera donc au même niveau que le répertoire www) et que dans ce dossier tu télécharges (avec Filezilla) un fichier texte nommé "Test.txt" qui contient ta clé de chiffrement. Tu pourras lire le contenu de ce fichier "Test.txt" à partir d'un fichier php (inclus dans le répertoire www) en faisant par exemple:

Code php :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
$key = null;
// pathinfo($_SERVER['DOCUMENT_ROOT'],PATHINFO_DIRNAME) -> retourne l'adresse du dossier parent de "www"
$keypath = pathinfo($_SERVER['DOCUMENT_ROOT'],PATHINFO_DIRNAME).'/CLES/Test.txt';
 
if(is_file($keypath))
{
	$key = file_get_contents($keypath);
}
else exit('clé de chiffrement introuvable');
 
define ('KEYBDD', $key);
// Contrôle  (en phase de développement) pour voir le résultat de la constante KEYBDD
var_dump(KEYBDD);
?>

Sinon pour le reste je ne vois pas pourquoi tu veux avoir deux bdd distinctes pour ton site.

[grunk]

"Protéger les clés secrètes, au minimum par la mise en œuvre de droits d’accès restrictifs et d’un mot de passe sûr."

Tu te fais des noeuds au cerveau pour rien.

En gros ca veux dire que tu place ta clé dans un dossier du serveur. (en dehors de la racine web) Ce dossier à des droit de lecture limité à l'utilisateur qui exécute php et apache (en général www-data) et ton serveur est protégé par mot de passe (comme n'importe quel serveur).
A partir de là tu remplis les cases "légales".

Il ne faut pas oublier que les recommandations de la CNIL vise un publique très large et ne sont bien souvent que du bon sens pour toutes personnes un minimum avertie.

[Coeur De Roses]

Bonjour, merci à vous deux.

Vraiment vous me débloquez davantage haha. Abciweb, côté serveur l'hebergeur à créer un dossier sites à la racine avec à l'interieur un dossier ayant le nom de domaine de mon site, sans passer par www. Je suis tellement Ko dans mon cerveau que je sais plus si c'est l'hebergeur qui a crée ce dossier à mon nom de domaine ou moi . Quand j'accède à ce site depuis le web, il est accessible, il n'ont donc pas crée de dossier www comme j'en ai en local pour le projet.

Quand je tape le code pour avoir le chemin, j'obtiens ça

Code :

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

pathinfo($_SERVER['DOCUMENT_ROOT'],PATHINFO_DIRNAME)  /home/clients/174ec013cdcc74b1c25a2d4dace20259/sites

Mais dans l'explorateur ça affiche juste / comme étant le lieu plus haut dans la racine, bon j'imagine que /home/clients/174ec013cdcc74b1c25a2d4dace20259 concerne des trucs techniques qu'on est pas sensé manipuler en tant que client d'hébergeur.

Peut être que pour ce cas de figure sites peut être considérer comme l'équivalent de www et que mon hebergeur n'utilise pas apache ou wamp. J'ai donc mis cdrjm_cle au même niveau que le dossier sites pour être hors racine web. En cherchant sur le web comment accéder à quelque chose situer sur la racine, j'ai trouver qu'il fallait mettre plusieurs fois ../ pour accéder à une chose situé depuis la racine du serveur. Dans mon cas j'ai fais 2 fois ../ et j'ai pu afficher une clé de test. Peut petre que ça peut sembler bête et facile mais pour moi c'est pas évident, vraiment XD.

J'ai mis ça

Code :

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

$chemin_de_la_cle ='../../cdrjm_cle/cle_test.txt';

et avec le code tu m'as passer j'ai pu afficher la clé. Je suis vraiment soulagé que ça marche.

Concernant le fait de vouloir deux bdd, bah je me suis peut être trop obstiner à vouloir faire comme indiquer sur la partie 5 Store the key on a different server, de la solution sur ce lien https://security.stackexchange.com/q...encryption-key.

Ca me semblait être la solution la moins prise de tête et la plus simple à mettre en place, bien que pas la meilleure.

Grunk, mdr bah franchement c'est une vrai galère pour moi sur ce problème, alors que j'imagine que techniquement c'est petit comparé à autre chose ou peut être très petit. J'ai mis des droits d'accès restricitifs avec le chmod disponible en interface sur le dossier pour que seul le propriétaire y ai accès. Quand la CNIL dit de mettre un mot de passe, j'ai pris ce qu'il fallait faire à la lettre bien que des fois il faut pas prendre ce qu'on dit à la lettre et voir le sens derrière la phrase. Mais j'étais persuadé qu'il fallait mettre un mot de passe pour le fichier.

L'explorateur qui gère les fichiers et dossiers serveur est nommé FTP manager chez mon hebergeur, avec un compte FTP que j'utilise qui possède effectivement un mot de passe, j'imagine que c'est peut être celui-ci dont tu parle concernant le mot de passe qui protège le serveur ?

[ABCIWEB]

Salut,

Effectivement l'organisation des dossiers peut varier suivant les hébergeurs. Maintenant si tu dois remonter au dossier parent de pathinfo($_SERVER['DOCUMENT_ROOT'],PATHINFO_DIRNAME) tu peux aussi utiliser "dirname" et faire

Code php :

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

1
2
3
$chemin_de_la_cle = dirname(pathinfo($_SERVER['DOCUMENT_ROOT'],PATHINFO_DIRNAME)).'/cdrjm_cle/cle_test.txt';
// ou 
$chemin_de_la_cle = dirname($_SERVER['DOCUMENT_ROOT'],2).'/cdrjm_cle/cle_test.txt';

L'intérêt d'utiliser $_SERVER['DOCUMENT_ROOT'] pour se positionner par rapport à cette variable serveur, c'est qu'elle te renverras toujours la même valeur quelque soit la position de ton script dans l'arborescence de ton site.

Quand tu utilises '../' pour remonter au répertoire parent, tu définis une adresse relative par rapport au script en cours. Si tu déplaces ton script dans un sous répertoire tu ne cibleras plus la même adresse et tu devras adapter ton code en conséquence. Donc dans ton cas de figure, l'utilisation de $_SERVER['DOCUMENT_ROOT'] te permettras d'avoir un code générique, qui résout également le problème d'adresse si tu inclues ton fichier (avec "include") dans d'autres fichiers qui sont dans des répertoires de niveaux différents. En résumer, utiliser '../' n'est pas bête, mais moins générique et il te faudrait ensuite faire attention au contexte d'utilisation de ton script.

je me suis peut être trop obstiner à vouloir faire comme indiquer sur la partie 5 Store the key on a different server

Tu viens de faire exactement ce qui est écrit, tes données chiffrées sont dans le serveur de la base de donnée et ta clé est sur le serveur de fichiers. Remarques que tu n'as pas accès au serveur de base de données depuis ton FTP, ce sont deux serveurs différents avec des mots de passe différents et des systèmes de gestion différents. Tu es ok comme ça.