LES LANDING PAGES ET LES FAILLES XSS

Sécurisation des landing pages et protection contre les failles XSS

Lorsque l’on aborde le sujet des développements web, l’une des questions majeures que l’on se pose est celle de la sécurité.
Et ce, spécifiquement quand des formulaires sont créés dans des landing pages.

Sécurisation des landing pages et protection contre les failles XSS

Le web est un terrain de jeu pour les pirates informatiques et les formulaires vulnérables. On peut rencontrer différents types d’attaques. Nous pourrions essayer de toutes les évoquer mais dans cet article nous n’aborderons que celles relatives aux failles XSS. Nous expliquerons de quoi il s’agit et comment l’éviter.

Pourquoi parler des failles XSS et pas d’une autre ?

Il s’agit d’une des failles les plus répandues dans les sites web dynamiques. Elle fait partie de la famille des attaques par injection, aussi appelée « Cross-Site Scripting », elle figure parmi le Top 10 des risques de sécurité de l’OWASP (Open Web Application Security Project : communauté en ligne qui travaille sur la sécurité des applications Web).

 

Les failles XSS, c’est quoi ?

Il s’agit d’attaques visant les sites web affichant dynamiquement du contenu utilisateur sans effectuer de contrôle et d’encodage des informations saisies par les utilisateurs. Ces attaques ont pour but notamment l’exécution de code à distance, l’injection SQL, la redirection de l’utilisateur, ou le vol d’informations (par exemple session et cookies).

Les possibilités des XSS sont très larges puisque l’attaquant peut utiliser tous les langages pris en charge par le navigateur (JavaScript, Java…) et de nouvelles possibilités sont régulièrement découvertes.

Comment éviter ces failles ?

Un certain nombre de précautions sont à prendre, parmi celles-ci :

1. L’encodage des caractères spéciaux
Parmi les caractères spéciaux, certains (par exemple : & < > ” ‘/) lorsqu’ils sont placés en entrée d’une ligne de commande ne sont pas interprétés comme des données mais comme du code. Ils peuvent donc être interprétés dans le code de la page et traiter. Leur utilisation doit être limitée et ceux-ci doivent être « échappés », c’est-à-dire remplacés par quelque chose qui ne sera pas interprété en front-end et back-end (par exemple leurs équivalents HTML).

2. Le contrôle des paramètres passés en argument, de leur valeur et de leur nom

3. La limitation de la longueur des données

4. La vérification du format des données entrées par l’utilisateur par la mise en place de pattern côté front-end et de regex côté back-end

Il existe un grand nombre d’outils dédiés à l’automatisation des tests d’intrusions, parmi ceux-ci il y a OWASP ZAP, Skipfish, Nessus/OpenVAS, etc…

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

GLOSSAIRE

Attaque par injection : permet à un pirate informatique de s’octroyer une entrée dans un programme, interprété comme une commande ou requête qui modifie le déroulement de l’exécution du logiciel ou code.

Injection SQL : attaque permettant d’injecter dans la requête SQL en cours un morceau de requête non prévu par le système et pouvant compromettre la sécurité.

Front-end : il s’agit du côté client (navigateur web), de la partie émergée d’un site web. Ce sont les éléments du site web que l’on aperçoit à l’écran et avec lesquels on peut interagir.

Back-end : il s’agit de la partie du site web qui n’est pas accessible aux utilisateurs et qui permet de gérer les contenus et les paramètres du site.

Pattern : l’attribut pattern spécifie une expression régulière définissant la règle avec laquelle valider la valeur de l’élement input.

Regex : (regular expression en anglais ou expression régulière) chaîne de caractères servant à décrire un ensemble de chaînes grâce à l’utilisation de caractères ayant une signification particulière qui pourra permettre par exemple de vérifier le format des données entrantes.

 

Aurore Cugnot, pôle conseil.

Retour en haut