La faille csrf en jquery ?
Fermé
coleminer
-
26 avril 2019 à 13:31
avion-f16 Messages postés 19246 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 21 avril 2024 - 7 mai 2019 à 17:56
avion-f16 Messages postés 19246 Date d'inscription dimanche 17 février 2008 Statut Contributeur Dernière intervention 21 avril 2024 - 7 mai 2019 à 17:56
A voir également:
- La faille csrf en jquery ?
- Faille whatsapp - Guide
- Faille google chrome - Guide
- Le jeton csrf est invalide que faire - Forum Consommation & Internet
- Faille xz - Guide
- Jquery refresh dom ✓ - Forum Javascript
1 réponse
avion-f16
Messages postés
19246
Date d'inscription
dimanche 17 février 2008
Statut
Contributeur
Dernière intervention
21 avril 2024
4 497
7 mai 2019 à 17:56
7 mai 2019 à 17:56
Bonjour,
CSRF est une attaque qui consiste à faire effectuer une action, à un internaute qui visite une page sous le contrôle d'un hacker, sur un serveur qui n'est pas sous son contrôle, en usurpant bien-sûr les privilèges de cet internaute. Cette attaque peut être réalisée aussi simplement qu'avec un formulaire : le formulaire, placé sur la page du hacker, contient les valeurs/champs que la hacker souhaite envoyer sous la forme d'une requête POST vers le serveur externe. Le formulaire est soumis automatiquement au chargement de la page avec un peu de JS, le visiteur n'a pas le temps d'intervenir. Étant donné que c'est le navigateur du visiteur qui transmet la requête POST au serveur, les cookies sont aussi soumis et donc, si le visiteur est authentifié sur le serveur ciblé, alors la requête est traitée par le serveur ciblé avec les privilèges de l'internaute.
On peut s'en protéger de plusieurs façons, notamment à l'aide de jetons (tokens). Le jeton, récupéré par le visiteur lorsqu'il accède au site légitime, doit être communiqué par le visiteur lui-même lorsqu'il soumet ensuite la requête POST (= soumission du formulaire). La solution la plus simple est d'insérer le token dans un champ caché du formulaire lorsque le serveur légitime envoie la page HTML. Le token est donc soumis en même temps que le formulaire.
La protection CSRF (le token) est une sécurité mise en place au niveau du serveur / backend.
Et on en vient à la question : le hacker pourrait en effet, sur sa page suspicieuse, effectuer une requête AJAX pour récupérer ce token, le placer dans son formulaire, avant de soumettre ce dernier. Heureusement, les navigateurs bloquent par défaut toutes les requêtes AJAX si la destination ne correspond pas à l'origine, d'où le nom "same-origin policy". Il s'agit là d'une sécurité au niveau du navigateur.
La "sécurité" du visiteur dépend donc bien des deux sécurités.
Si les navigateurs n'incluaient pas cette sécurité (same-origin policy), l'application / le site légitime ne risqueraient pas grand chose car le hacker ne pourrait, en fin de compte, effectuer "que" les mêmes actions que le visiteur pourrait vouloir faire de son gré. Mais cela poserait de nombreux désagréments pour les deux côtés (visiteur + propriétaire du site), d'autant plus que parmi ces actions possibles, il y a la lecture d'infos confidentielles.
Les visiteurs devraient analyser chaque site qu'ils visitent pour s'assurer qu'il n'y ait pas de tels formulaires ou scripts AJAX cachés, avant d'exécuter le JS de la page. Surfer sur le Web serait un véritable cauchemar, d'où le fait que tous les navigateurs doivent intégrer la same-origin policy.
S'il était possible de désactiver la "same-origin policy" dans les options du navigateurs, le visiteur se mettrait en situation de risque lui-même, mais cela ne concernerait pas les autres visiteurs ni même l'application légitime en elle-même.
Il est possible, au niveau du serveur (via tout ce qui permet de modifier les entêtes HTTP : PHP, .haccess, configuration globale de Apache/Nginx, reverse proxy, ...) de modifier la règle "same-origin policy" (voir CORS = Cross-origin resource sharing) pour autoriser d'autres sites légitimes à récupérer des informations par AJAX, mais cela est plutôt risqué, on préfère généralement d'autres méthodes pour communiquer des informations entre serveurs/apps.
Il est donc toujours nécessaire d'inclure la protection CSRF lors du traitement des actions privilégiées, au niveau des fichiers PHP si c'est le langage utilisé coté backend. Qu'importe comment l'action est initialisée, de manière "classique" (formulaire, liens, ...) ou par AJAX.
La protection "same orgin policy" permet de s'assurer que le hacker ne récupère pas le token.
C'est même bien plus important que ça, en fait : elle permet de s'assurer qu'aucun site externe ne vole des informations confidentielles à l'aide de AJAX.
CSRF est une attaque qui consiste à faire effectuer une action, à un internaute qui visite une page sous le contrôle d'un hacker, sur un serveur qui n'est pas sous son contrôle, en usurpant bien-sûr les privilèges de cet internaute. Cette attaque peut être réalisée aussi simplement qu'avec un formulaire : le formulaire, placé sur la page du hacker, contient les valeurs/champs que la hacker souhaite envoyer sous la forme d'une requête POST vers le serveur externe. Le formulaire est soumis automatiquement au chargement de la page avec un peu de JS, le visiteur n'a pas le temps d'intervenir. Étant donné que c'est le navigateur du visiteur qui transmet la requête POST au serveur, les cookies sont aussi soumis et donc, si le visiteur est authentifié sur le serveur ciblé, alors la requête est traitée par le serveur ciblé avec les privilèges de l'internaute.
On peut s'en protéger de plusieurs façons, notamment à l'aide de jetons (tokens). Le jeton, récupéré par le visiteur lorsqu'il accède au site légitime, doit être communiqué par le visiteur lui-même lorsqu'il soumet ensuite la requête POST (= soumission du formulaire). La solution la plus simple est d'insérer le token dans un champ caché du formulaire lorsque le serveur légitime envoie la page HTML. Le token est donc soumis en même temps que le formulaire.
La protection CSRF (le token) est une sécurité mise en place au niveau du serveur / backend.
Et on en vient à la question : le hacker pourrait en effet, sur sa page suspicieuse, effectuer une requête AJAX pour récupérer ce token, le placer dans son formulaire, avant de soumettre ce dernier. Heureusement, les navigateurs bloquent par défaut toutes les requêtes AJAX si la destination ne correspond pas à l'origine, d'où le nom "same-origin policy". Il s'agit là d'une sécurité au niveau du navigateur.
La "sécurité" du visiteur dépend donc bien des deux sécurités.
Si les navigateurs n'incluaient pas cette sécurité (same-origin policy), l'application / le site légitime ne risqueraient pas grand chose car le hacker ne pourrait, en fin de compte, effectuer "que" les mêmes actions que le visiteur pourrait vouloir faire de son gré. Mais cela poserait de nombreux désagréments pour les deux côtés (visiteur + propriétaire du site), d'autant plus que parmi ces actions possibles, il y a la lecture d'infos confidentielles.
Les visiteurs devraient analyser chaque site qu'ils visitent pour s'assurer qu'il n'y ait pas de tels formulaires ou scripts AJAX cachés, avant d'exécuter le JS de la page. Surfer sur le Web serait un véritable cauchemar, d'où le fait que tous les navigateurs doivent intégrer la same-origin policy.
S'il était possible de désactiver la "same-origin policy" dans les options du navigateurs, le visiteur se mettrait en situation de risque lui-même, mais cela ne concernerait pas les autres visiteurs ni même l'application légitime en elle-même.
Il est possible, au niveau du serveur (via tout ce qui permet de modifier les entêtes HTTP : PHP, .haccess, configuration globale de Apache/Nginx, reverse proxy, ...) de modifier la règle "same-origin policy" (voir CORS = Cross-origin resource sharing) pour autoriser d'autres sites légitimes à récupérer des informations par AJAX, mais cela est plutôt risqué, on préfère généralement d'autres méthodes pour communiquer des informations entre serveurs/apps.
Il est donc toujours nécessaire d'inclure la protection CSRF lors du traitement des actions privilégiées, au niveau des fichiers PHP si c'est le langage utilisé coté backend. Qu'importe comment l'action est initialisée, de manière "classique" (formulaire, liens, ...) ou par AJAX.
La protection "same orgin policy" permet de s'assurer que le hacker ne récupère pas le token.
C'est même bien plus important que ça, en fait : elle permet de s'assurer qu'aucun site externe ne vole des informations confidentielles à l'aide de AJAX.
