{"id":1753,"date":"2015-08-19T00:00:00","date_gmt":"2015-08-19T00:00:00","guid":{"rendered":"http:\/\/v32019.vaadata.com\/blog?p=1753"},"modified":"2020-12-23T11:57:02","modified_gmt":"2020-12-23T10:57:02","slug":"proteger-votre-site-bonnes-pratiques-de-securite-pour-php-2","status":"publish","type":"post","link":"https:\/\/www.vaadata.com\/blog\/fr\/proteger-votre-site-bonnes-pratiques-de-securite-pour-php-2\/","title":{"rendered":"Prot\u00e9ger votre site : Bonnes pratiques de s\u00e9curit\u00e9 pour PHP #2"},"content":{"rendered":"\n

Mis \u00e0 jour : 23 D\u00e9c 2020<\/em><\/p>\n\n\n\n

Cet article ne remplace pas de bonnes connaissances en PHP<\/strong>, 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, en comprenant et en appliquant les diff\u00e9rents points en fonction de vos besoins et de votre contexte.<\/p>\n\n\n\n

Cet article est le deuxi\u00e8me de notre s\u00e9rie d\u00e9di\u00e9e \u00e0 la s\u00e9curit\u00e9 pour PHP. Le premier article \u201cProt\u00e9ger votre site : Bonnes pratiques de s\u00e9curit\u00e9 pour PHP #1<\/a>\u201d vous donne des indications pour la configuration de PHP, les mises \u00e0 jour, l\u2019organisation du code ainsi que le filtrage\/\u00e9chappement des donn\u00e9es<\/strong>.<\/p>\n\n\n\n

Nous allons \u00e0 pr\u00e9sent examiner les attaques les plus courantes<\/strong>, ainsi que les moyens de s’en d\u00e9fendre.<\/strong><\/p>\n\n\n\n\n\n\n\n\n\n

\"Arr\u00eater<\/figure><\/div>\n\n\n\n

Injections SQL<\/h2>\n\n\n\n

Les injections SQL sont vraiment d\u00e9vastatrices, mais peuvent \u00eatre \u00e9vit\u00e9es en suivant quelques \u00e9tapes simples.<\/p>\n\n\n\n

Premi\u00e8rement, assurez-vous que les privil\u00e8ges utilisateurs dans la base de donn\u00e9es sont limit\u00e9s (principe de moindre privil\u00e8ge). Par exemple, les actions r\u00e9alis\u00e9es par un utilisateur front-office dans la base de donn\u00e9es devraient \u00eatre ex\u00e9cut\u00e9es par un utilisateur n\u2019ayant des droits que sur les tables li\u00e9es aux fonctionnalit\u00e9s front-end. S\u2019il n\u2019y a pas besoin de supprimer les donn\u00e9es d\u2019une table sp\u00e9cifique, alors ne donnez pas les droits de suppression \u00e0 cet utilisateur sur cette table.<\/p>\n\n\n\n

Ensuite, filtrez et nettoyez les donn\u00e9es servant d\u2019entr\u00e9e aux instructions SQL (vous pouvez vous r\u00e9f\u00e9rer \u00e0 la section filtrage et \u00e9chappement des donn\u00e9es de notre premier article<\/a>).
Un moyen plus efficace pour se prot\u00e9ger des injections SQL (mais ne rempla\u00e7ant pas le filtrage des donn\u00e9es) est l\u2019utilisation des \u201cprepared statements\u201d (requ\u00eates param\u00e9tr\u00e9es).
Pour voir comment impl\u00e9menter les requ\u00eates param\u00e9tr\u00e9es : http:\/\/php.net\/manual\/fr\/pdo.prepared-statements.php<\/a><\/p>\n\n\n\n\n\n

Injections de commandes<\/h2>\n\n\n\n

Utiliser des ex\u00e9cutions de commandes via votre code PHP est tr\u00e8s puissant, mais aussi tr\u00e8s dangereux si les pr\u00e9cautions n\u00e9cessaires ne sont pas prises.
Il est donc recommand\u00e9 de d\u00e9sactiver les fonctions dangereuses avec la directive disable_functions (dans le fichier php.ini).
De plus, une fois d\u00e9sactiv\u00e9es, ces fonctions ne pourront pas \u00eatre utilis\u00e9es par un pirate cr\u00e9ant son propre code PHP via une potentielle autre faille.<\/p>\n\n\n\n

disable_functions = show_source, exec, shell_exec, system, passthru, proc_open, popen, curl_exec, curl_multi_exec, parse_ini_file, show_source<\/p>\n\n\n\n

Lors de l\u2019utilisation de ces fonctions (si vous en avez absolument besoin), faites tr\u00e8s attention aux param\u00e8tres pass\u00e9s en entr\u00e9e. Vous devez vous assurer que les donn\u00e9es sont strictement valid\u00e9es avec des listes blanches, et\/ou filtr\u00e9es.
Les commandes dans leur globalit\u00e9 ainsi que les arguments peuvent \u00eatre \u00e9chapp\u00e9s via les fonctions natives escapeshellcmd (http:\/\/php.net\/manual\/fr\/function.escapeshellcmd.php<\/a>) et escapeshellarg (http:\/\/php.net\/manual\/fr\/function.escapeshellarg.php<\/a>).<\/p>\n\n\n\n\n\n

Vols de sessions<\/h2>\n\n\n\n

Les sessions reposent sur des identifiants de session.
Une attaque fr\u00e9quente est la fixation de session, consistant \u00e0 donner un identifiant de session \u00e0 une victime avant que celle-ci ne s\u2019identifie sur l\u2019application, puis \u00e0 utiliser ce m\u00eame identifiant de session afin de r\u00e9cup\u00e9rer la session de la victime.<\/p>\n\n\n\n

Pour \u00e9viter de tels probl\u00e8mes, quelques r\u00e8gles doivent \u00eatre suivies :<\/p>\n\n\n\n