Injection XSS
Principe de l'attaque
L'injection HTML/JavaScript, aussi appelée Cross-Site Scripting ou XSS, est une vulnérabilité qui permet à un attaquant d'insérer du code JavaScript malveillant dans une page Web, qui sera ensuite exécuté dans le navigateur de la victime.
L'njection XSS peut être utilisée pour voler des informations sensibles, comme les cookies de session, ou pour effectuer des actions au nom de la victime.
Il existe 3 types principaux d'attaques XSS :
-
Reflected XSS (XSS réfléchi) :
Ce type d'attaque se produit lorsque l'application Web prend une entrée de l'utilisateur et la renvoie immédiatement, sans la valider ou la désinfecter correctement. L'attaquant doit convaincre la victime de cliquer sur un lien malveillant qui contient le script injecté.
Le script est "réfléchi" par le serveur Web dans la réponse HTTP et exécuté par le navigateur de la victime.
-
Stored XSS (XSS persistant) :
Dans ce type d'attaque, le script malveillant est permanent et stocké sur le serveur. Il est ensuite renvoyé et exécuté dans le navigateur des utilisateurs chaque fois qu'ils accèdent à la page affectée.
Cela peut se produire si une application Web stocke les commentaires des utilisateurs et les affiche sur une page sans désinfecter correctement l'entrée.
-
DOM-based XSS (XSS basé sur le DOM) :
Cette attaque se produit lorsque le script malveillant manipule le DOM (Document Object Model) d'une page Web, modifiant sa structure.
Cela peut se produire si une application utilise les données fournies par l'utilisateur pour manipuler le DOM sans les valider ou les désinfecter correctement.
Chacun de ces types d'attaques a ses propres caractéristiques, mais tous ont en commun le fait qu'ils permettent à un attaquant d'exécuter du code JavaScript dans le navigateur d'un utilisateur.
Moyens de lutte
-
Utilisation de
htmlspecialchars(): Cette fonction convertit les caractères spéciaux en entités HTML. Cela peut aider à empêcher l'exécution de scripts malveillants insérés dans les entrées utilisateur qui sont ensuite affichées sur une page Web.En savoir plus sur htmlspecialchars()
La fonction
htmlspecialcharsen PHP est une fonction intégrée qui convertit les caractères spéciaux en entités HTML.C'est un outil précieux pour prévenir les attaques de type Cross-Site Scripting (XSS) en assurant que les données entrées par l'utilisateur sont affichées telles quelles et ne sont pas interprétées comme du code HTML ou JavaScript.
Voici comment elle est généralement utilisée :
echo htmlspecialchars('<script>alert("XSS Attack");</script>');En sortie, cela donnera :
<script>alert("XSS Attack");</script>Ainsi, le code potentiellement malveillant n'est pas exécuté, mais simplement affiché en tant que texte brut.
Exemple d'une fonction complète pour nettoyer les entrées utilisateur
function sanitizeInput($data) {
$data = trim($data);
$data = stripslashes($data);
$data = htmlspecialchars($data);
return $data;
}Cette fonction
sanitizeInput()supprime d'abord les espaces inutiles, puis élimine les antislashs, et enfin convertit les caractères spéciaux en entités HTML avechtmlspecialchars. -
Content Security Policy (CSP) : CSP est une politique de sécurité qui aide à détecter et à atténuer certains types d'attaques, y compris les injections de données et les attaques XSS. Une CSP peut être utilisée pour spécifier les sources à partir desquelles le navigateur est autorisé à charger des ressources.
En savoir plus sur la Content Security Policy
La politique de sécurité du contenu (Content Security Policy ou CSP) est une mesure de sécurité qui aide à détecter et à atténuer certains types d'attaques, notamment les attaques de Cross Site Scripting (XSS) et les injections de données.
CSP fonctionne en permettant aux serveurs Web de spécifier une liste blanche d'origines de ressources autorisées. Cela peut inclure des scripts, des images, des feuilles de style, et plus encore. Par exemple, une CSP peut spécifier que seuls les scripts provenant du domaine d'origine du site Web peuvent être exécutés, bloquant ainsi tout script provenant d'un autre domaine.
La CSP est mise en œuvre via un en-tête HTTP spécial que le serveur envoie au navigateur. Lorsque le navigateur reçoit cet en-tête, il respecte les directives spécifiées dans la politique. Si une page ou un script tente d'accéder à une ressource qui n'est pas sur la liste blanche, le navigateur bloque l'accès et génère généralement un message d'erreur dans la console du développeur.
Comment ajouter un en-tête HTTP dans une application Web écrite en PHP ?
Il suffit d'utiliser la fonction
header()de PHP. Cette fonction est utilisée pour envoyer un en-tête HTTP brut.Voici comment vous pouvez l'utiliser pour définir une politique de sécurité de contenu :
<?php
header("Content-Security-Policy: default-src 'self';");
?>Dans cet exemple,
default-src 'self';est une directive qui indique que tous les contenus (scripts, images, CSS, etc.) doivent provenir du même domaine que la page.La fonction
header()doit être appelée avant tout contenu réel qui est envoyé, car elle fait partie de l'en-tête HTTP. -
Cookies HttpOnly : L'attribut HttpOnly peut être défini sur les cookies pour empêcher que les scripts côté client ne puissent y accéder. Cela peut aider à protéger les données sensibles stockées dans les cookies.
En savoir plus sur les cookies HttpOnly
Les "cookies HttpOnly" sont un type de cookies HTTP qui ne peuvent pas être accédés par des scripts côté client, tels que JavaScript. Cela signifie qu'ils sont accessibles uniquement par le serveur.
L'attribut HttpOnly a été introduit pour aider à atténuer le risque d'attaques par cross-site scripting (XSS), qui peuvent être utilisées pour voler des informations sensibles. Avec un cookie HttpOnly, même si un script malveillant réussit à s'exécuter sur la page, il ne sera pas en mesure de lire le cookie.
Comment un cookie peut-il être accessible uniquement par le serveur, alors qu'un cookie est par nature enregistré sur le poste client par le navigateur ?
Lorsqu'on dit qu'un "cookie HttpOnly" est accessible uniquement par le serveur, cela signifie que le cookie ne peut être lu ou modifié par des scripts côté client, comme JavaScript, qui s'exécutent dans le navigateur de l'utilisateur. Le cookie est toujours stocké sur le poste client, mais l'attribut HttpOnly limite la manière dont il peut être accédé.
Lorsqu'un serveur envoie un cookie à un navigateur, il peut inclure l'attribut
HttpOnlydans l'en-têteSet-Cookie. Cela indique au navigateur de marquer le cookie comme HttpOnly. Une fois qu'un cookie a été marqué comme HttpOnly, le navigateur ne permettra pas à des scripts côté client d'accéder au cookie. Cependant, lorsque le navigateur envoie des requêtes ultérieures au serveur, il inclura toujours le cookie dans l'en-tête de la requête HTTP, ce qui permet au serveur d'y accéder. -
Validation et assainissement des entrées : Il est important de toujours valider et assainir les entrées utilisateur. PHP propose plusieurs fonctions pour cela, par exemple
filter_var(). L'assainissement peut inclure l'élimination des balises HTML, la vérification de l'adéquation des données avec le type attendu, etc.En savoir plus sur filter_var()
La fonction
filter_var()en PHP est une fonction intégrée qui permet de filtrer une variable avec un filtre spécifié. Elle est souvent utilisée pour valider et nettoyer les données fournies par l'utilisateur.Voici comment elle est généralement utilisée pour valider une adresse e-mail :
$email = "someone@example.com";
if (filter_var($email, FILTER_VALIDATE_EMAIL)) {
echo("$email is a valid email address");
} else {
echo("$email is not a valid email address");
}Dans cet exemple,
FILTER_VALIDATE_EMAILest un filtre qui valide l'adresse e-mail. Si l'adresse e-mail est valide, la fonction retourne l'adresse e-mail, sinon elle retourne false.Exemple d'une fonction complète pour nettoyer et valider une adresse e-mail
function sanitizeAndValidateEmail($email) {
$email = filter_var($email, FILTER_SANITIZE_EMAIL);
if (filter_var($email, FILTER_VALIDATE_EMAIL)) {
return $email;
} else {
return false;
}
}Cette fonction
sanitizeAndValidateEmailutilise d'abordFILTER_SANITIZE_EMAILpour supprimer tous les caractères illégaux de l'adresse e-mail, puisFILTER_VALIDATE_EMAILpour vérifier si l'adresse e-mail est valide. -
Utilisation de bibliothèques éprouvées : Il existe plusieurs bibliothèques et frameworks qui offrent des mécanismes de protection contre les attaques XSS. Par exemple, le composant
Escaperde Zend Framework, ou le composantTwigde Symfony qui échappe automatiquement les variables de sortie. -
Mise à jour régulière des dépendances : Assurez-vous que toutes vos dépendances, y compris votre version de PHP et tous les packages que vous utilisez, sont à jour. Les mises à jour de sécurité sont souvent incluses dans ces mises à jour.
En résumé, la protection contre les attaques XSS nécessite une approche globale de la sécurité. Il n'y a pas de solution unique, mais une combinaison de plusieurs méthodes peut grandement augmenter la sécurité de votre application.