PHP-MYSQL BONNES PRATIQUES DE SECURITE

[crocodudule]

Bonjour à tous, cela faisait un certain temps que j'étais pas venu coté forum!

Depuis des années je code mes sites selon des bases "classiques" presque invariables:

. "protection" des données de formulaire avec htmlspecialchars ou intval avant tout traitement ou enregistrement en base,

. aucun mot de passe en clair stocké, uniquement des hash (à minima sha1) avec sel,

. cryptage/chiffrement des informations sensibles contenues dans la base etc...

. accès aux pages sensibles par session et/ou htaccess

Et au détour d'une conversation sur les news, un commentaire m'a donné une bonne astuce si le site n'est pas en SSH, à savoir utiliser une extension jquery pour ne transmettre que le hash du mot de passe à la connexion. Pas bête ! Puis j'ai découvert une extension jquery (validate) qui permet rapidement de vérifier ce qui est entré dans les formulaires etc...

Naturellement, de tels astuces sont facilement contournables et donc ne dispensent pas de faire ses vérifications à l'ancienne coté php avant tout traitement.

Néanmoins et comme il est toujours bon d'apprendre, je vous sollicite afin de savoir si vous avez d'autres bonnes astuces ou pratiques de sécurité qui, sans demander des moyens énormes, permettent d'améliorer la sauce habituelle?

A votre bon cœur!

Merci :)

(si la mayonnaise prend sur ce post, je l'éditerai pour lister dans un topic unique les astuces et bonnes pratiques).

[latlanh]

Il y a 21 minutes, crocodudule a écrit :

Néanmoins et comme il est toujours bon d'apprendre, je vous sollicite afin de savoir si vous avez d'autres bonnes astuces ou pratiques de sécurité qui, sans demander des moyens énormes, permettent d'améliorer la sauce habituelle?

Perso pour moi la meilleur astuce est de ne pas faire de PHP

[crocodudule]

Il y a 11 minutes, latlanh a écrit :

Perso pour moi la meilleur astuce est de ne pas faire de PHP

Mais vu que le titre de mon post porte sur PHP/MYSQL pour des raisons évidentes de facilité de déploiement, je cherche pas ici à connaitre des astuces sur Ruby par exemple... 

[Cara62]

On 20/02/2018 at 11:49 AM, latlanh said:

Perso pour moi la meilleur astuce est de ne pas faire de PHP

Couché, couché salle bête  

 

On 20/02/2018 at 11:27 AM, crocodudule said:

Bonjour à tous, cela faisait un certain temps que j'étais pas venu coté forum!

Depuis des années je code mes sites selon des bases "classiques" presque invariables:

. "protection" des données de formulaire avec htmlspecialchars ou intval avant tout traitement ou enregistrement en base,

. aucun mot de passe en clair stocké, uniquement des hash (à minima sha1) avec sel,

. cryptage/chiffrement des informations sensibles contenues dans la base etc...

. accès aux pages sensibles par session et/ou htaccess

Et au détour d'une conversation sur les news, un commentaire m'a donné une bonne astuce si le site n'est pas en SSH, à savoir utiliser une extension jquery pour ne transmettre que le hash du mot de passe à la connexion. Pas bête ! Puis j'ai découvert une extension jquery (validate) qui permet rapidement de vérifier ce qui est entré dans les formulaires etc...

Naturellement, de tels astuces sont facilement contournables et donc ne dispensent pas de faire ses vérifications à l'ancienne coté php avant tout traitement.

Néanmoins et comme il est toujours bon d'apprendre, je vous sollicite afin de savoir si vous avez d'autres bonnes astuces ou pratiques de sécurité qui, sans demander des moyens énormes, permettent d'améliorer la sauce habituelle?

A votre bon cœur!

Merci :)

(si la mayonnaise prend sur ce post, je l'éditerai pour lister dans un topic unique les astuces et bonnes pratiques).

Salut,

T'inquiètes pas, il faut pas écouter les haters :) 

 

Le premier gros conseil, c'est déjà de passer par un framework PHP, qui concrètement va gérer cette partie sécurité, données utilisateurs, formulaires, sessions etc.... 

Sinon pour rester sur du php "classique", déjà faut avoir la version php à jour, la dernière LTS est la version 5.6, elle ne sera plus supporté niveau sécurité en décembre 2018. Donc il faut passer sur du PHP7 minimum, il devrait avoir bientôt la prochaine LTS.

Pour les formulaires, outre le fait qu'il faut bien sûr échapper le html, il faut aussi les protéger avec un token csrf

Vérifier à chaque fois côté serveur que les données du formulaires sont bien ceux attendues, un email est bien un email etc....  

Tes requêtes sql (update, insert) il ne faut pas les exécuter directement mais les préparer ensuite les exécuter 

Les mots de passes doivent être stockés avec un algo très fort, le gros conseil c'est d'utiliser crypt , sha1 est obsolète.

Si l'utilisateur doit retrouver son mdp, surtout ne jamais l'envoyer en clair par email (ou autre), toujours lui proposer de reset son mdp. (Pour le coup avec crypt pas le choix)

Concernant les pages admins, etc... Pour moi une gestion de rôles  côté serveur suffit. 

Concernant l'application php en elle même, il faut faire un .htaccess pour que seul le dossier "public" soit accessible, tout le reste de ton code doit être ailleurs, ça évitera qu'une personne essaie de remonter dans les dossiers. Concrètement  tu auras juste un fichier index.php, tout le reste sera dans d'autres dossiers, connexion sql, users etc... Voici un exemple

Le site doit être full https, serveur web à jour.

 

Enfin, le meilleur conseil que je peux te donner : "il ne faut jamais faire confiance à l'utilisateur". 

 

Si tu as d'autres question n'hésite pas  

 

 

 

 

 

 

 

 

 

[crocodudule]

Il y a 15 heures, Cara62 a écrit :

Le premier gros conseil, c'est déjà de passer par un framework PHP, qui concrètement va gérer cette partie sécurité, données utilisateurs, formulaires, sessions etc.... 

Sinon pour rester sur du php "classique", déjà faut avoir la version php à jour, la dernière LTS est la version 5.6, elle ne sera plus supporté niveau sécurité en décembre 2018. Donc il faut passer sur du PHP7 minimum, il devrait avoir bientôt la prochaine LTS.

Pour les formulaires, outre le fait qu'il faut bien sûr échapper le html, il faut aussi les protéger avec un token csrf

Vérifier à chaque fois côté serveur que les données du formulaires sont bien ceux attendues, un email est bien un email etc....  

Tes requêtes sql (update, insert) il ne faut pas les exécuter directement mais les préparer ensuite les exécuter 

Les mots de passes doivent être stockés avec un algo très fort, le gros conseil c'est d'utiliser crypt , sha1 est obsolète.

Si l'utilisateur doit retrouver son mdp, surtout ne jamais l'envoyer en clair par email (ou autre), toujours lui proposer de reset son mdp. (Pour le coup avec crypt pas le choix)

Concernant les pages admins, etc... Pour moi une gestion de rôles  côté serveur suffit. 

Concernant l'application php en elle même, il faut faire un .htaccess pour que seul le dossier "public" soit accessible, tout le reste de ton code doit être ailleurs, ça évitera qu'une personne essaie de remonter dans les dossiers. Concrètement  tu auras juste un fichier index.php, tout le reste sera dans d'autres dossiers, connexion sql, users etc... Voici un exemple

Le site doit être full https, serveur web à jour.

Enfin, le meilleur conseil que je peux te donner : "il ne faut jamais faire confiance à l'utilisateur". 

Si tu as d'autres question n'hésite pas

Merci pour ton retour!

Effectivement je sais que le SHA1 est limite aujourd'hui, lorsque la plateforme le permet j'utilise d'autres méthodes.

Très intéressant le coup du token que j'avais jusqu'ici zappé, mais en réalité je le faisais sans en connaître la dénomination en générant un hash avec une chaine composée du pseudo de session plus un RANDOM (token que je double avec une pseudo gestion des droits pour chaque user, droit qui conditionne en dur l'affichage ou non du formulaire). Tu penses que la méthode proposée sur ton lien apporte un plus significatif en terme de sécurité ?

Enfin, là où tu m’intéresses, c'est sur les framework PHP gérant l'aspect sécurité, tu me conseilles quoi pour une approche relativement simple?

[Chocobidou]

Sinon pour les échanges clients-serveur , je vous invite a regarder du coté des JSON Web Token. c'est cool, ça va vite et c'est sécurisé. Après je ne sais pas si il y a de quoi gérer ça en PHP, je fais du Java et du TS/JS avec Angular.

[Cara62]

9 hours ago, Chocobidou said:

Sinon pour les échanges clients-serveur , je vous invite a regarder du coté des JSON Web Token. c'est cool, ça va vite et c'est sécurisé. Après je ne sais pas si il y a de quoi gérer ça en PHP, je fais du Java et du TS/JS avec Angular.

On peut gérer le JWT avec PHP sans soucis. Après je peux me tromper, mais je vois pas trop l'intérêt de ce genre de système dans une application monolithique, de mon avis c'est plus orienté pour les web services. 

12 hours ago, crocodudule said:

Merci pour ton retour!

Effectivement je sais que le SHA1 est limite aujourd'hui, lorsque la plateforme le permet j'utilise d'autres méthodes.

Très intéressant le coup du token que j'avais jusqu'ici zappé, mais en réalité je le faisais sans en connaître la dénomination en générant un hash avec une chaine composée du pseudo de session plus un RANDOM (token que je double avec une pseudo gestion des droits pour chaque user, droit qui conditionne en dur l'affichage ou non du formulaire). Tu penses que la méthode proposée sur ton lien apporte un plus significatif en terme de sécurité ?

Enfin, là où tu m’intéresses, c'est sur les framework PHP gérant l'aspect sécurité, tu me conseilles quoi pour une approche relativement simple?

Le principe du token csrf c'est d'empêcher le formulaire de se faire "hack", il assure que c'est la même personne qui remplit et submit le formulaire. C'est clairement une sécurité de base pour les formulaires. 

 

 

Concernant les frameworks, c'est un sujet assez complexe. ça dépend énormément de ton niveau en dev, du projet en lui même etc... 

Déjà je suis pro Symfony donc je vais pas être très objectif :)

Mais le problème de Symfony c'est que c'est un "gros" framework, et c'est vraiment pas facile à appréhender, et finalement, utiliser du Symfony pour par exemple faire un simple blog, c'est totalement contre productif. (C'est comme utiliser un tank pour détruire une bouteille   ).

Dans le même genre il y a aussi Laravel (j'ai essayé un peu, mais j'ai pas accroché, purement subjectif, et il y a aucun soucis, il est excellent aussi)

 

Alors ce que je viens de dire à propos de Symfony est vrai pour la version 2/3, où quand tu "installes" Symfony, tu as de base environ 40 modules (formulaires, gestion bdd etc...), et donc pas mal de modules dont tu te serviras jamais.

Sauf que pour Symfony 4 (sorti fin 2017), ils ont fait un virage à 180°,  désormais tu as que des fonctionnalités de base, et si tu en veux d'autres (ex : gestion des formulaires), tu dois les installer manuellement. (Après en soit c'est pas compliqué tu fais ça en 1 ligne de commande).

Tout ça pour dire, que pour Symfony 4, la philosophie est totalement différente des anciennes versions, on parle plus de "micro framework", où tu as juste le minimum syndical, et tu dois installer (ou dev) le reste. 

 

 

Et de mon avis, si tu es débutant en dev (ou pour des petits projets), passer par un micro framework peut être vraiment intéressant pour toi.

Tu as notamment, Silex (qui est le petit frère de Symfony), donc tu as juste la base de Symfony, le reste c'est en plus :) 

Après comme je le dis précédemment Symfony 4 passe sur une philosophie de micro framework, donc utiliser Silex devient un peu obsolète à mon goût, et du coup autant passer à du Symfony 4 directement. 

Tu as aussi Slim qui est un excellent micro framework. (Jamais essayé)

Enfin un autre que je connais (de nom) c'est CakePHP

 

 

Pour en revenir à Symfony/Silex (oui je suis objectif  ), le gros avantage, c'est qu'il y a une énorme communauté derrière,  et si t'as besoins de certaines fonctionnalités pour ton application il y a de forte probabilité que quelqu'un l'a dev. 

Ou si tu rencontres des problèmes lié à Symfony, tu trouves facilement des solutions avec une simple recherche Google. 

Sans parler de la tonne de tutos dispo sur internet  

 

 

De tout façon, c'était loin d'être une liste exhaustive (orienté Symfony?  ), il en existe beaucoup, mais je te conseille quand même d'en choisir un qui est toujours maintenu, et aussi bien sûr que tu as du feeling avec (parcours les docs etc...), car ça sera quand même ton compagnon de dev  . 

 

 

Enfin un bonus pour toi, je te conseille la chaine YT de l'AFUP spécialisé dans les conférences PHP, et tu apprendras beaucoup de choses dans l'univers du PHP, et même parfois plus généralement dans le dev, tu as aussi des conférences sur la sécurité qui devrait t'intéresser je pense  

 

 

 

 

 

 

[crocodudule]

Merci pour tous ces renseignements, je retrouve l'esprit du forum que j'avais laissé il y a quelques années

Je vais me pencher sur les frameworks que jusqu'ici j'associais dans mon esprit à des modules de fonctionnalités mais sans me dire que ça pouvait également concerner la sécurité.

Si je trouve mon bonheur (probablement dans les micros), je ferai un petit édit de mon post initial pour présenter le framework choisi et son usage en terme de sécu :)

 

 

[revker]

J'apporte ma petite pierre au topic.

Je suis programmeur PHP/SQL/JS depuis une dizaine d'années. J'ai surtout fait et fais toujours d'ailleurs du Zend Framework et du Symfony.

En ce moment, je suis sur PHP 7.2, ZF3. La base de données est cachée dernière une api de webservices développée en Java JEE 7.

Je suis d'accord avec ce qui a été dit par @Cara62, la protection des données est très importante mais les frameworks modernes couvrent un large spectre à ce niveau; on ne fait plus grand chose "manuellement". Le routeur en est le parfait exemple puisqu'il permet de bien filtrer les urls. En général, les applications sont faites en modèle MVC pour bien séparer les couches. Concernant, la base de données, le plus "simple" est d'utiliser un ORM, d'ailleurs Doctrine était installé par défaut avant Symfony 4. Je mets "simple" entre guillemets car le mapping des entités est parfois complexe surtout si la base de données a été mal pensée dès le départ. Toujours en accord avec ce qui a été dit, il faut rapidement mettre à jour sa version de PHP, plus tôt c'est fait, moins le pas est grand à franchir lorsque sa version n'est plus supportée.  D'ailleurs PHP 7 apporte un gain de performances phénoménal sans compter l'ajout de fonctionnalités bienvenues comme le typage des scalaires ou de pouvoir spécifier le retour des fonctions. C'est le top. 

J'étais aux Forums PHP 2016 et 2017, c'est vraiment top de rencontrer des intervenants qui viennent présenter les difficultés qu'ils ont rencontré sur de gros projets. Il y a toujours moyen d'apprendre quelques petits astuces et le buffet est plutôt bon 

[Chocobidou]

On 22/02/2018 at 21:32, Cara62 a écrit :

On peut gérer le JWT avec PHP sans soucis. Après je peux me tromper, mais je vois pas trop l'intérêt de ce genre de système dans une application monolithique, de mon avis c'est plus orienté pour les web services. 

Le principe du token csrf c'est d'empêcher le formulaire de se faire "hack", il assure que c'est la même personne qui remplit et submit le formulaire. C'est clairement une sécurité de base pour les formulaires. 

 

 

le tuto developpez.com si ça t’intéresse -> http://eleven-labs.developpez.com/tutoriels/angular2-symfony3/creer-rapidement-systeme-authentification/

L'avantage c'est que tu es 100% stateless

[Cara62]

38 minutes ago, Chocobidou said:

le tuto developpez.com si ça t’intéresse -> http://eleven-labs.developpez.com/tutoriels/angular2-symfony3/creer-rapidement-systeme-authentification/

L'avantage c'est que tu es 100% stateless

Vraiment pas convaincu pour du monolithique, surtout avec du symfony où tu as un système d'authentification déjà intégré. :) 

[revker]

Il y a 4 heures, Cara62 a écrit :

Vraiment pas convaincu pour du monolithique, surtout avec du symfony où tu as un système d'authentification déjà intégré. :) 

Symfony fait trop de choses "magiquement", je n'aime pas du tout cet aspect du framework.

[Aloyse57]

Il y a 9 minutes, revker a écrit :

Symfony fait trop de choses "magiquement", je n'aime pas du tout cet aspect du framework.

C'est ce que j'aime dans ces frameworks : on se concentre sur la valeur-ajoutée et on produit rapidement des programmes complexes sans devoir se taper des déclarations qu'on a déjà fait 1000x. Ça évite de réinventer la roue, mais il faut se taper la doc en long et en large et accepter que certains trucs resteront complètement opaques ("magique", c'est une bonne description ).

Mais, c'est super important de connaître de quoi est fait le framework et comprendre comment il fonctionne. C'est quasiment vital, car tôt ou tard on frappe un mur technique et sans maîtriser les fondamentaux, on est coincé. Je vois beaucoup de mes jeunes collègues qui ne savent pas s'en sortir en dehors du framework habituel, faute de plus larges connaissances. C'est un problème majeur pour leur carrière.

[Cara62]

13 minutes ago, revker said:

Symfony fait trop de choses "magiquement", je n'aime pas du tout cet aspect du framework.

Comme tous les frameworks et encore laravel c'est bien pire je trouve, ils utilisent le systèmes des façades pour cacher encore plus le code. 

Mais la pour le coup Symfony ou pas, ça change pas que utiliser du jwt dans une application monolithique je vois vraiment pas l'intérêt.

Je dis pas que c'est useless jwt, on va l'utiliser pour faire des Web services. Mais notre application métier restera avec son propre système d'authentification. 

[revker]

Il y a 10 minutes, Aloyse57 a écrit :

C'est ce que j'aime dans ces frameworks : on se concentre sur la valeur-ajoutée et on produit rapidement des programmes complexes sans devoir se taper des déclarations qu'on a déjà fait 1000x. Ça évite de réinventer la roue, mais il faut se taper la doc en long et en large et accepter que certains trucs resteront complètement opaques ("magique", c'est une bonne description ).

Mais, c'est super important de connaître de quoi est fait le framework et comprendre comment il fonctionne. C'est quasiment vital, car tôt ou tard on frappe un mur technique et sans maîtriser les fondamentaux, on est coincé. Je vois beaucoup de mes jeunes collègues qui ne savent pas s'en sortir en dehors du framework habituel, faute de plus larges connaissances. C'est un problème majeur pour leur carrière.

On est d'accord, quand on est pas passé par les bases que sont la POO, les design patterns ou le code pur et dur sans framework, on est vite perdu quand on s'aventure en dehors des clous. Avec Symfony, on progresse vite au début mais pour passer de débutant à confirmé la marge est très haute par contre. En ça, je préfère Zend qui te force à configurer beaucoup plus de choses mais au moins tu comprends tout ce qui se passe (pas à 100% mais 80% au moins).

Il y a 11 minutes, Cara62 a écrit :

Comme tous les frameworks et encore laravel c'est bien pire je trouve, ils utilisent le systèmes des façades pour cacher encore plus le code. 

Mais la pour le coup Symfony ou pas, ça change pas que utiliser du jwt dans une application monolithique je vois vraiment pas l'intérêt.

Je dis pas que c'est useless jwt, on va l'utiliser pour faire des Web services. Mais notre application métier restera avec son propre système d'authentification. 

En effet, JWT a un intérêt pour communiquer avec une api. Par exemple, tu peux t'en servir derrière du oAuth2 pour les tokens qui transitent entre les applications. Ca permet à ton token de véhiculer plus d'informations par exemple.

Et le token CSRF,  c'est même pas négociable. Si tu passes un audit de sécurité et que tes formulaires n'en possèdent pas, c'est recalage directement :/

[Cara62]

De tout façon il faut maîtriser la poo et les design pattern avant de s'attaquer à un framework. 

Et il faut comprendre comment fonctionne le framework,  sa philosophie etc... 

Le problème avec symfony, c'était la standard édition où de base tu as environ 45 composants. Quand tu débutes en symfony c'est très lourd à absorber. Il y a tellement de choses à apprendre.

Et je pense c'est l'une des raisons du virage à 180 pour symfony 4.

[foetus]

Il y a 3 heures, Cara62 a écrit :

De tout façon il faut maîtriser la poo et les design pattern avant de s'attaquer à un framework.

Bof  avant de faire des classes et d'appliquer des solutions à des problèmes que l'on ne connait pas/ peu, ... il faut savoir ce qu'est un serveur HTTP : routage d'URL, interaction avec la base de données, génération de requêtes (en JSON et en HTML), logique métier, ... dans un premier temps

Et dans un deuxième temps, il y a : la sécurité (classique avec SQL préparé + hachage), les cookies, l'authentification et un peu d'optimisation (qui est généralement ORM et "view as a template"), ...

Et dans un troisième temps, il y a : la sécurité (token, OAuth2), la charge/ le cache, maitriser Apache/ nginx, ...