{"id":1754,"date":"2015-08-26T00:00:00","date_gmt":"2015-08-26T00:00:00","guid":{"rendered":"http:\/\/v32019.vaadata.com\/blog?p=1754"},"modified":"2021-02-02T11:55:15","modified_gmt":"2021-02-02T10:55:15","slug":"proteger-votre-site-bonnes-pratiques-de-securite-pour-php-3","status":"publish","type":"post","link":"https:\/\/www.vaadata.com\/blog\/fr\/proteger-votre-site-bonnes-pratiques-de-securite-pour-php-3\/","title":{"rendered":"Prot\u00e9ger votre site : Bonnes pratiques de s\u00e9curit\u00e9 pour PHP #3"},"content":{"rendered":"\n<p><em>Mis \u00e0 jour : 23 D\u00e9c 2020<\/em><\/p>\n\n\n\n<p>Cet article ne remplace pas de bonnes connaissances en\u00a0PHP, mais peut vous donner de r\u00e9els bons conseils pour booster votre s\u00e9curit\u00e9.<br>Il n\u2019y aura ici rien \u00e0 copier\/coller directement dans vos fichiers PHP. Cependant, nous croyons que ces conseils et bonnes pratiques vous apporteront des b\u00e9n\u00e9fices \u00e0 long terme, en comprenant et en appliquant les diff\u00e9rents points en fonction de vos besoins et de votre contexte.<\/p>\n\n\n\n<p>Cet article est le troisi\u00e8me de notre s\u00e9rie d\u00e9di\u00e9e \u00e0 la s\u00e9curit\u00e9 pour PHP.<br><a href=\"https:\/\/www.vaadata.com\/blog\/fr\/bonnes-pratiques-de-securite-pour-php-partie-1-proteger-votre-site\/\">Le premie<\/a><a href=\"https:\/\/www.vaadata.com\/blog\/fr\/bonnes-pratiques-de-securite-pour-php-partie-1-proteger-votre-site\/\" target=\"_blank\" rel=\"noreferrer noopener\">r article<\/a> vous donne des indications pour la configuration de PHP, les mises \u00e0 jour, le filtrage des donn\u00e9es, ainsi que l\u2019organisation du code.<br>Le second article traite de la protection <a href=\"https:\/\/www.vaadata.com\/blog\/fr\/proteger-votre-site-bonnes-pratiques-de-securite-pour-php-2\/\" target=\"_blank\" rel=\"noreferrer noopener\">contre les attaques les plus courantes<\/a>.<\/p>\n\n\n\n<p>Nous allons maintenant traiter des risques li\u00e9s aux cookies, uploads, CRSF ainsi que de la s\u00e9curit\u00e9 par l&rsquo;obscurit\u00e9.<\/p>\n\n\n\n<!--more-->\n\n\n\n<h2 class=\"wp-block-heading\">Prot\u00e9ger vos cookies<\/h2>\n\n\n\n<p>Ne stockez pas d\u2019informations sensibles dans les cookies. Les cookies sont par nature non s\u00e9curis\u00e9s, vous ne pouvez pas compter sur eux pour stocker (temporairement ou non) des donn\u00e9es sensibles.<br>Pour prot\u00e9ger vos cookies contre les manipulations de donn\u00e9es, une bonne solution est de les signer en calculant un hash (avec grain de sel), pour que le serveur puisse v\u00e9rifier leurs contenus.<br>Ce hash doit \u00eatre inclus dans les cookies eux-m\u00eames, et r\u00e9cup\u00e9r\u00e9 par le serveur.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Uploads de fichiers<\/h2>\n\n\n\n<p>Les envois de fichiers sont une fonctionnalit\u00e9 tr\u00e8s sensible, car ils permettent \u00e0 des utilisateurs d\u2019envoyer des fichiers sur votre propre serveur. Une impl\u00e9mentation fragile permettra \u00e0 des attaquants d\u2019envoyer des fichiers PHP dans des r\u00e9pertoires ex\u00e9cutables, leur donnant la possibilit\u00e9 de faire \u00e0 peu pr\u00e8s tout sur le serveur.<\/p>\n\n\n\n<p><br>Il n\u2019existe pas de solution parfaite et simple. Il est donc n\u00e9cessaire d\u2019adopter une strat\u00e9gie de d\u00e9fense en profondeur :<\/p>\n\n\n\n<ol class=\"wp-block-list\"><li>Ne permettre l\u2019envoi de fichiers qu\u2019aux utilisateurs authentifi\u00e9s<\/li><li>Limiter la taille des fichiers envoy\u00e9s<\/li><li>Limiter les extensions et formats<\/li><li>Cr\u00e9er un fichier .htaccess dans le r\u00e9pertoire parent des uploads de fichiers, sp\u00e9cifiant la liste des extensions autoris\u00e9es. Exemple de directives, \u00e0 adapter en fonction de votre contexte :<br><em>deny from all<\/em><br><em>&lt;Files ~ \u201c^w+.(gif|jpe?g|png|pdf)$\u201d&gt;<\/em><br><em>order deny,allow<\/em><br><em>allow from all<\/em><br><em>&lt;\/Files&gt;<\/em><\/li><li>Valider le type de fichier (valider avec une liste blanche les types de fichiers, et v\u00e9rifier le type MIME)<\/li><li>Lors de l\u2019enregistrement des fichiers : <ol><li>G\u00e9n\u00e9rer le nom des fichiers de mani\u00e8re al\u00e9atoire et ne pas se reposer sur des noms fournis par les utilisateurs<\/li><li>Utiliser des noms uniques<\/li><li>V\u00e9rifier que l\u2019emplacement du fichier n\u2019est pas d\u00e9j\u00e0 utilis\u00e9<\/li><li>Sauvegarder les fichiers en dehors du dossier racine du site<\/li><li>Apr\u00e8s avoir enregistr\u00e9 les fichiers, retirer les permissions d\u2019ex\u00e9cution sur le fichier (chmod) <\/li><\/ol><\/li><\/ol>\n\n\n\n<p>La taille maximale des fichiers envoy\u00e9s peut \u00eatre configur\u00e9e de mani\u00e8re globale dans le param\u00e8tre upload_max_filesize du php.ini. Si vous souhaitez d\u00e9finir une taille inf\u00e9rieure pour un formulaire en particulier, vous pouvez utiliser le param\u00e8tre MAX_FILE_SIZE du formulaire, mais effectuez une seconde v\u00e9rification c\u00f4t\u00e9 PHP, puisque ce param\u00e8tre peut \u00eatre modifi\u00e9 par l\u2019utilisateur lors de la soumission du fichier.<\/p>\n\n\n\n<p>V\u00e9rifications compl\u00e9mentaires :<br>Si vous attendez une image de la part de l\u2019utilisateur, vous pouvez par exemple v\u00e9rifier la taille de cette derni\u00e8re avec getimagesize. Si \u201cfalse\u201d est retourn\u00e9, alors l\u2019image n\u2019est pas valide.<br>Pour aller un peu plus loin, le contenu du fichier peut \u00eatre analys\u00e9, par exemple avec ClamAV.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Cross Site Request Forgery (CSRF)<\/h2>\n\n\n\n<p>Une premi\u00e8re r\u00e8gle consiste \u00e0 impl\u00e9menter toutes les actions impliquant des changements d\u2019\u00e9tat via des requ\u00eates POST, au lieu de requ\u00eates GET. Cela ne permettra pas en soi de supprimer le risque d\u2019attaques CSRF, mais r\u00e9duira le risque d\u2019attaques basiques.<br>Pour vous prot\u00e9ger contre <a href=\"https:\/\/www.vaadata.com\/blog\/fr\/comprendre-les-vulnerabilites-web-en-5-min-episode-8-csrf-cross-site-request-forgery\/\" target=\"_blank\" rel=\"noreferrer noopener\">les attaques CSRF<\/a>, l\u2019utilisation de jetons anti-CSRF dans les formulaires est n\u00e9cessaire. Ces tokens, stock\u00e9s dans la session de l\u2019utilisateur, seront compar\u00e9s avec les valeurs retourn\u00e9es par les utilisateurs afin de valider\/rejeter les actions.<br>Si vous n\u2019utilisez pas de framework permettant l\u2019impl\u00e9mentation directe de ce type de token, vous devrez alors les impl\u00e9menter par vous-m\u00eame, ou utiliser une librairie tierce. L\u2019OWASP fournit un bon exemple d\u2019impl\u00e9mentation, sur <a href=\"https:\/\/www.owasp.org\/index.php\/PHP_CSRF_Guard\" target=\"_blank\" rel=\"noreferrer noopener\">cette page<\/a>.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">La s\u00e9curit\u00e9 par l&rsquo;obscurit\u00e9<\/h2>\n\n\n\n<p>L\u2019obscurit\u00e9 n\u2019est pas un moyen d\u2019emp\u00eacher les attaques, mais peut r\u00e9ellement ralentir les attaquants et cacher des informations pr\u00e9cieuses qu\u2019ils recherchent.<\/p>\n\n\n\n<p>Vous pouvez par exemple cacher la version de PHP utilis\u00e9e (des headers), en param\u00e9trant expose_php \u00e0 false dans le php.ini.<\/p>\n\n\n\n<p>Un autre exemple est le formulaire de login : lorsque les utilisateurs fournissent des identifiants erron\u00e9s, il n\u2019est pas n\u00e9cessaire de d\u00e9tailler la raison pr\u00e9cise (par exemple : mauvais mot de passe). Se contenter de dire \u00e0 l\u2019utilisateur que les identifiants ne sont pas corrects est suffisant, et ne permettra pas \u00e0 l\u2019attaquant de conna\u00eetre un login valide.<\/p>\n\n\n\n<p>L\u2019impl\u00e9mentation de s\u00e9curit\u00e9 est un processus continu et complexe. Tout d\u2019abord, car celle-ci d\u00e9pend de votre contexte particulier. Ensuite, parce que des nouveaux types d\u2019attaques apparaissent au fil du temps.<\/p>\n\n\n\n<p>Les diff\u00e9rentes bonnes pratiques \u00e9voqu\u00e9es dans cette s\u00e9rie d\u2019articles permettent de se prot\u00e9ger contre des vuln\u00e9rabilit\u00e9s techniques majeures, mais pas contre <a href=\"https:\/\/www.vaadata.com\/blog\/fr\/que-sont-les-failles-logiques-sur-les-applications-web\/\" target=\"_blank\" rel=\"noreferrer noopener\">des failles logiques<\/a>. En tant que designer fonctionnel et d\u00e9veloppeur web, vous devez \u00e9galement vous assurer que votre logique m\u00e9tier est sans faille et qu&rsquo;elle ne peut pas \u00eatre contourn\u00e9e ou abus\u00e9e. Il n\u2019y a pas de solution automatis\u00e9e et g\u00e9n\u00e9rique contre cela, mis \u00e0 part la revue de la logique de vos processus avec votre \u00e9quipe.<\/p>\n\n\n\n<p>Les frameworks de d\u00e9veloppement r\u00e9cents peuvent aussi vous aider \u00e0 mettre en place des mesures de s\u00e9curit\u00e9, ceux-ci incluant des solutions et patterns faciles \u00e0 activer. Cependant, ces fonctionnalit\u00e9s de s\u00e9curit\u00e9 sont \u00e9galement faciles \u00e0 d\u00e9sactiver, et toute erreur de configuration peut avoir un impact n\u00e9gatif. Il est donc important de pr\u00eater une attention toute particuli\u00e8re aux documentations d\u00e9taillant l\u2019utilisation de ces briques de s\u00e9curit\u00e9. Les frameworks sont un bon moyen de b\u00e9n\u00e9ficier de l\u2019exp\u00e9rience d\u2019autres d\u00e9veloppeurs, et d\u2019utiliser du code maintenu.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Mis \u00e0 jour : 23 D\u00e9c 2020 Cet article ne remplace pas de bonnes connaissances en\u00a0PHP, mais peut vous donner de r\u00e9els bons conseils pour booster votre s\u00e9curit\u00e9.Il n\u2019y aura ici rien \u00e0 copier\/coller directement dans vos fichiers PHP. Cependant, nous croyons que ces conseils et bonnes pratiques vous apporteront des b\u00e9n\u00e9fices \u00e0 long terme,<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14],"tags":[],"class_list":{"0":"post-1754","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-technique"},"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/1754","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/comments?post=1754"}],"version-history":[{"count":6,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/1754\/revisions"}],"predecessor-version":[{"id":3503,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/posts\/1754\/revisions\/3503"}],"wp:attachment":[{"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/media?parent=1754"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/categories?post=1754"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vaadata.com\/blog\/fr\/wp-json\/wp\/v2\/tags?post=1754"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}