Comment construire une page web sécurisée en PHP : Partie 1

PHP est un outil puissant qui est souvent utilisé pour créer des sites web. Cependant, comme la plupart des logiciels, il peut être sujet à une multitude de problèmes de sécurité, à la fois dans son implémentation et dans son utilisation. Pour cette raison, une pléthore de cyber-attaques ciblent les applications PHP et une grande partie d’entre elles sont même des logiciels malveillants automatisés qui parcourent l’internet.

Dans cet article, je partage avec vous une liste de vulnérabilités avec les sites web PHP qui sont couramment ciblés et des exemples de code pour corriger ces problèmes. Veuillez noter qu’il ne s’agit pas d’une liste exhaustive, il existe de nombreuses vulnérabilités courantes qui ne sont pas abordées ici et qui pourraient l’être dans d’autres articles.

Injection SQL

Les injections SQL représentent une vulnérabilité courante qui peut être remarquablement simple à résoudre. L’astuce consiste à séparer les données et la requête, ce qui peut être fait comme indiqué ci-dessous lorsqu’on utilise PHP Data Objects (PDO) comme pilote SQL. La concaténation de l’entrée avec la requête ne doit jamais être faite manuellement car elle permet une entrée arbitraire qui pourrait être malveillante. Les fonctions intégrées telles que “prepare” et “execute” aideront à filtrer les entrées malveillantes d’une manière qui a été testée et approuvée par la communauté, ce qui la rend beaucoup plus résistante.

$query = "DELETE FROM website.Session WHERE (User_ID = :user_id AND Session_ID = :session_id)";

$values = array(':session_id' => session_id(), ":user_id" => $user_id);

try {

$delete = $PDO->prepare($query);

$delete->execute($values);

} catch(PDOException $exception) {

throw new Exception("Database failure!");

}

L’utilisation correcte de PDO est une chose, mais il faut également modifier les paramètres de PDO pour s’assurer que les données ne sont pas interprétées. Autoriser l’interprétation des données permettrait une entrée malveillante puisqu’un acteur malveillant pourrait tromper l’interprète en lui faisant croire que les données ou une partie d’entre elles font partie de la requête. Sachant cela, un simple changement dans les paramètres PDO empêchera cela, mais il est également recommandé d’activer la gestion des erreurs, car l’enregistrement des erreurs a tendance à mener à la découverte de bogues.

$PDO = new PDO($CONNECTION_STRING, $USER, $PASSWORD);

$PDO->setAttribute(PDO::ATTR_EMULATE_PREPARES, False); // Disables interpretation

$PDO->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); // Enables errors

Cross-Site Scripting (XSS)

Les XSS sont des attaques très importantes dont la nature est similaire à celle des injections SQL puisqu’elles tentent toutes deux d’injecter du code malveillant. Mais pour prévenir les XSS, il faut principalement procéder à une vérification des entrées et à un encodage correct des caractères de contrôle. Cela se fait principalement à l’aide de deux fonctions : “strip_tags()” et “htmlspecialchars()“. La première, “strip_tags()” permet au développeur de supprimer les balises HTML et PHP de n’importe quelle entrée basée sur une chaîne de caractères. C’est très bien, mais ce n’est pas suffisant pour toutes les attaques XSS. Parfois, l’XSS utilisera l’encodage de caractères pour essayer de contourner cette suppression des balises de code.

Pour éviter cela et autoriser les caractères spéciaux dans une entrée, l’utilisation de la fonction “htmlspecialchars()” convertira les caractères spéciaux en entités HTML. Ce faisant, l’entrée ne sera pas interprétée par l’utilisateur final, ce qui permet d’éviter la plupart des attaques XSS. Il convient de noter que toute entrée utilisateur peut être malveillante, c’est pourquoi il est généralement recommandé d’assainir toutes les entrées utilisateur. L’utilisation de fonctions intégrées pour la désinfection des entrées est préférable, principalement parce qu’elles ont été testées et approuvées par la communauté.

Hachage de mot de passe

Les algorithmes de hachage sont souvent une partie négligée des applications web, ce qui, je suppose, est dû au fait que le choix du bon algorithme de hachage n’est important qu’après qu’une brèche se soit produite, car avant cela, on ne voit que très peu d’impact. Mais dans ce cas, il est généralement préférable d’utiliser SHA3 ou ARGON2ID comme algorithme de hachage dans le contexte de PHP. SHA3 est préférable car c’est un algorithme post-quantique qui est standardisé. ARGON2ID est préférable car c’est l’algorithme le plus puissant disponible en natif dans la plupart des fonctions PHP liées à la gestion des mots de passe. Il convient de noter que même si l’on utilise le bon algorithme, l’implémentation et l’utilisation de celui-ci peuvent le rendre vulnérable.

Une façon d’éviter cela est d’utiliser des fonctions intégrées conçues pour cet usage. Un bon exemple est d’utiliser les fonctions “password_hash()“, “password_verify()” & “password_needs_rehash()“. Ces fonctions sont intégrées, testées et approuvées par la communauté, ce qui signifie qu’elles vous protègent contre plus que l’utilisation du bon algorithme, “password_verify()” vous protège également contre les attaques temporelles qui pourraient être utilisées pour déterminer si un utilisateur existe ou des parties du mot de passe.

Les cookies

Les cookies sont une partie importante des applications web; ils permettent aux développeurs de stocker des informations sur le navigateur, ce qui facilite la conception du site web, mais on oublie souvent qu’ils ont des propriétés en plus d’une valeur. Par exemple, la propriété “SameSite” vous permet de restreindre les sites web qui peuvent accéder aux cookies. Naturellement, vous souhaitez que seul votre site web puisse accéder aux cookies, c’est pourquoi il est préférable de définir cette propriété sur “Strict”.

La propriété “Secure” vous permet également de protéger la confidentialité du cookie, car le navigateur ne partage le cookie que sur des canaux sécurisés, généralement HTTPS, mais aussi d’autres protocoles cryptés. Il est donc préférable d’activer cette propriété.

“HTTPOnly” est une propriété qui indique au navigateur que le cookie ne doit pas être accessible aux API côté client comme Javascript. Par conséquent, si votre cookie n’est pas utilisé par des scripts ou s’il est possible de faire en sorte qu’il ne soit pas utilisé par des scripts côté client, il est préférable d’activer cette propriété. Principalement parce que cela empêchera les scripts malveillants ou les attaques telles que XSS d’accéder au contenu du cookie.

session_start(['cookie_lifetime' => 604800, 'cookie_samesite' => 'Strict', 'cookie_secure' => true, 'cookie_httponly' => true]); // 7 days cookie lifetime

Inutile de dire qu’il existe de nombreuses autres vulnérabilités. En voici quelques-unes pour ceux qui souhaitent en savoir plus sur le sujet : include injection, command injection, directory traversal, XML attacks & object injection.