PHP : la bonne pratique

Apprendre les bonnes pratiques de programmation en PHP

X. Sécurité▲

X-A. La sécurité dans une application web▲

De nombreuses personnes mal intentionnées tenteront d'exploiter les possibles failles dans votre application web. Il est important que vous ayez conscience de cela et que vous preniez les précautions nécessaires afin de renforcer la sécurité dans votre application. Heureusement, les gens du projet « Open Web Application Security » (OWASP en anglais) ont compilé une liste exhaustive des principaux problèmes de sécurité connus et les méthodes pour vous en prémunir. C'est une lecture indispensable pour tout développeur consciencieux de la sécurité.

Lire le guide de sécurité OWASP

X-B. Hachage de mots de passe▲

Pratiquement tout le monde construit une application PHP qui se base sur une authentification de l'utilisateur. Les identifiants et les mots de passe sont stockés dans une base de données et utilisés plus tard pour authentifier les utilisateurs.

Il est important que vous utilisiez correctement les fonctions de hachage avant de les stocker. Le hachage de mots de passe est une opération irréversible produisant une chaîne de caractères de longueur fixe. Cela signifie que vous pouvez comparer le produit d'une fonction de hachage avec le hash stocké en base de données pour déterminer s'il s'agit du même texte. Si les mots de passe stockés en base de données ne sont pas « hachés », alors n'importe qui ayant accès à cette base peut compromettre les comptes utilisateurs. Il arrive souvent que les utilisateurs utilisent le même mot de passe pour d'autres services, c'est pourquoi il faut prendre la sécurité des informations avec sérieux.

Hachage de mots de passe avec password_hash

La fonction password_hash a été introduite avec la version 5.5 de PHP. À l'heure actuelle, elle utilise BCrypt qui est l'algorithme le plus robuste. Cela va être mis à jour dans le futur afin de supporter plus d'algorithmes. La bibliothèque password_compat a été créée afin de fournir une compatibilité ascendante avec PHP >= 5.3.7.

Dans l'exemple ci-dessous, nous hachons une chaîne de caractères et faisons une vérification sur une chaîne différente. Étant donné que les deux chaînes sont différentes (‘secret-password' vs. ‘bad-password'), l'authentification va échouer.

Sélectionnez

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

<?php
                      
require 'password.php';

$passwordHash = password_hash('secret-password', PASSWORD_DEFAULT);

if (password_verify('bad-password', $passwordHash)) {
    // Mot de passe correct
} else {
    // Mauvais mot de passe
}

X-C. Filtrage des données▲

Une règle d'or : ne jamais faire confiance aux entrées extérieures dans votre code PHP. Prenez toujours soin de « nettoyer » et de valider ces entrées avant de les utiliser dans le code. Les fonctions filter_var et filter_input peuvent nettoyer les entrées textuelles et valider les données comme les emails.

Les entrées étrangères viennent de n'importe où : les données de formulaire envoyées via $_GET ou $_POST, des valeurs dans la variable superglobales $_SERVER et le corps des requêtes HTTP via fopen('php://input', 'r'). N'oubliez pas, les entrées étrangères ne se limitent pas aux données envoyées par l'utilisateur. Les fichiers uploadés et téléchargés, les valeurs de session, les données des cookies et les données provenant de services tiers sont aussi des entrées étrangères.

Demandez-vous à chaque fois que vous traitez, affichez, concaténez ou incluez des données dans votre code si ces données ont été correctement filtrées et qu'elles peuvent être considérées comme sures.

Les données peuvent être filtrées différemment selon le contexte. Par exemple, quand des données brutes sont envoyées en sortie vers la page HTML, elles peuvent exécuter du JavaScript et du HTML. Cette technique est connue sous le nom de « Cross-Site Scripting » (XSS) et peut se révéler très dangereuse. Une façon d'éviter les attaques XSS est de nettoyer toutes les données générées par l'utilisateur avant de les afficher sur votre page en retirant toutes balises HTML avec la fonction strip_tags ou en échappant les caractères spéciaux tels que ‘<' ou ‘>' avec les fonctions htmlentities ou htmlspecialchars.

Un autre exemple est lorsque l'on passe des options à exécuter en ligne de commandes. Cela peut être très dangereux (et est souvent une mauvaise idée), mais vous pouvez utiliser la fonction escapeshellarg pour nettoyer les arguments d'une commande.

Un dernier exemple concerne le fait d'autoriser les entrées étrangères pour déterminer le fichier à télécharger depuis le système de fichiers. Cela peut être exploité en changeant le chemin vers le fichier. Vous devez supprimer « / », « ../ », les octets null ou d'autres caractères du chemin de façon à empêcher le chargement de fichiers cachés, privés ou contenant des données sensibles.

X-C-1. Nettoyage▲

Le « nettoyage » supprime (ou échappe) les caractères illégaux ou considérés comme dangereux.

Par exemple, vous devriez nettoyer les entrées étrangères avant d'inclure les entrées en HTML ou de les insérer dans une requête SQL. Si vous utilisez les paramètres liés avec PDO, il nettoiera les entrées pour vous.

Parfois il est nécessaire d'autoriser certains tags HTML dans les entrées quand on les inclut dans la page HTML. Cela se révèle souvent très compliqué à mettre en œuvre et beaucoup l'évite, c'est pourquoi il existe des syntaxes de formatage telles que Markdown or BBCode bien que des bibliothèques comme HTML Purifier vous permettent d'intégrer directement du HTML. Voir les filtres de nettoyage

X-C-2. Validation▲

La validation s'assure que les entrées extérieures correspondent à ce que vous vous attendiez. Par exemple, vous pourriez vouloir valider une adresse email, un numéro de téléphone ou un âge lors du traitement de l'enregistrement d'un compte.

Voir les filtres de validation

X-D. Fichiers de configuration▲

Lorsque vous créez des fichiers de configuration pour vos applications, les meilleures pratiques recommandent que les méthodes ci-dessous soient suivies :

il est recommandé que vous stockiez vos informations de configuration là où aucun utilisateur non autorisé ne peut y accéder (via le système de fichier) ;
si vous devez stocker vos fichiers de configuration à la racine du projet, nommer les fichiers avec l'extension .php. Cela permet de s'assurer que même si le fichier est accédé directement, il ne s'affichera pas en texte brut ;
les informations contenues dans les fichiers de configuration doivent être protégées correctement, que ce soit via le chiffrage et/ou via le système de permissions des utilisateurs/groupes du système de fichiers.

X-E. Register Globals▲

** NOTE : ** Depuis la version 5.4.0 de PHP, le paramètre register_globals a été retiré et ne peut plus être utilisé. Les applications plus anciennes n'afficheront plus qu'un avertissement si ce paramètre est utilisé.

Quand il est activé, le paramètre de configuration register_globals permet à plusieurs types de variables (cela inclut notamment les paramètres $_POST, $_GET and $_REQUEST) d'être accessibles partout dans votre application. Cela peut facilement conduire à des problèmes de sécurité étant donné que votre application ne peut de façon claire dire d'où proviennent les données.

Par exemple: $_GET['foo'] sera accessible via $foo ce qui peut écraser des variables non encore déclarées. Si vous utilisez PHP < 5.4.0 assurez-vous que ce paramètre est à off.

Register_globals dans le manuel PHP

X-F. Rapport d'erreurs▲

La journalisation des erreurs peut être utile pour repérer les points qui posent problème dans votre application, mais cela permet aussi d'afficher des informations sur la structure de votre application au monde extérieur. Pour vous protéger efficacement contre ce genre de problèmes, vous avez besoin de configurer votre serveur différemment entre la version de développement et celle pour la production.

X-F-1. Développement▲

Pour afficher toutes les erreurs possibles durant le développement, configurez les paramètres suivants dans votre fichier php.ini :

Sélectionnez

1.
2.
3.
4.

display_errors = On
display_startup_errors = On
error_reporting = -1
log_errors = On

En passant la valeur -1 , toutes les erreurs possibles seront affichées, même lors de l'ajout d'autres niveaux et constantes dans les futures versions de PHP. La constante E_ALL fonctionne de la même façon depuis PHP 5.4. - php.net

Le niveau d'erreur E_STRICT a été introduit avec PHP 5.3.0 et ne fait pas partie de E_ALL, cependant il est dorénavant inclus dans E_ALL depuis la 5.4.0. Pour pouvoir rapporter toutes les erreurs en 5.3, il est donc nécessaire d'utiliser soit -1 ou E_ALL | E_STRICT.

Rapporter toutes les erreurs possibles par version PHP

< 5.3 -1 ou E_ALL
5.3 -1 ou E_ALL | E_STRICT
> 5.3 -1 ou E_ALL

X-F-2. Production▲

Pour cacher l'affichage d'erreurs dans votre environnement de production, configurez votre fichier php.ini de cette façon :

Sélectionnez

1.
2.
3.
4.

display_errors = Off
display_startup_errors = Off
error_reporting = E_ALL
log_errors = On

Avec ces paramètres, les erreurs seront toujours enregistrées dans les journaux d'erreurs de votre serveur web, mais ne seront pas affichées à l'utilisateur. Pour plus d'informations sur ces paramètres, voir le manuel PHP: