Résumé de gestion
L'équipe Centralized Exchange a contacté Sayfer afin d'effectuer des tests de pénétration complets de la boîte noire sur leur application Web et un examen de la boîte blanche pour leur architecture cryptographique en décembre 2021.
Avant d'évaluer les services ci-dessus, nous avons organisé une réunion de lancement avec l'équipe technique de Centralized Exchange et avons reçu un aperçu du système et des objectifs de cette recherche.
Au cours de la période de recherche de 4 semaines, nous avons découvert 10 vulnérabilités dans le système. Les vulnérabilités les plus dangereuses étaient l'injection SQL et les failles de la logique métier.
L'impact sur le système est critique car un attaquant malveillant pourrait exploiter certaines de ces vulnérabilités pour profiter du système, soit en changeant son rôle d'utilisateur en "super_user" via l'injection SQL, soit en abusant du système et en volant de l'argent à l'échange centralisé. en utilisant le mécanisme de mise à jour du système 30s.
Vulnérabilités par risque
Haute – Menace directe sur les processus métier clés.
Moyenne – Menace indirecte sur les processus métier clés ou menace partielle sur les processus métier.
Faible – Aucune menace directe n'existe. La vulnérabilité peut être exploitée à l'aide d'autres vulnérabilités.
D'information – Cette constatation n'indique pas de vulnérabilité, mais énonce un commentaire qui signale des défauts de conception et une mise en œuvre incorrecte qui pourraient causer un problème à long terme.
Approche
Méthodologie d'évaluation de la sécurité
Sayfer utilise OWASP WSTG comme norme technique lors de l'examen des applications Web. Après avoir acquis une compréhension approfondie du système, nous avons décidé quels tests OWASP sont nécessaires pour évaluer le système.
Évaluation de sécurité
Après avoir compris et défini la portée, effectué une modélisation des menaces et évalué les tests corrects requis afin de vérifier entièrement l'application pour les failles de sécurité, nous avons effectué notre évaluation de la sécurité.
La collecte d'informations
La collecte d'informations | Nom du test |
WSTG-INFO-01 | Effectuer une reconnaissance de découverte de moteur de recherche pour les fuites d'informations |
WSTG-INFO-02 | Serveur Web d'empreintes digitales |
WSTG-INFO-03 | Examiner les métafichiers du serveur Web pour détecter les fuites d'informations |
WSTG-INFO-04 | Énumérer les applications sur le serveur Web |
WSTG-INFO-05 | Examiner le contenu de la page Web pour détecter les fuites d'informations |
WSTG-INFO-06 | Identifier les points d'entrée de l'application |
WSTG-INFO-07 | Mapper les chemins d'exécution via l'application |
WSTG-INFO-08 | Cadre d'application Web d'empreintes digitales |
WSTG-INFO-09 | Application Web d'empreintes digitales |
WSTG-INFO-10 | Architecture des applications cartographiques |
Configuration et déploiement des tests de gestion
Configuration et déploiement des tests de gestion | Nom du test |
WSTG-CONF-01 | Tester la configuration de l'infrastructure réseau |
WSTG-CONF-02 | Tester la configuration de la plate-forme d'application |
WSTG-CONF-03 | Tester la gestion des extensions de fichiers pour les informations sensibles |
WSTG-CONF-04 | Examiner l'ancienne sauvegarde et les fichiers non référencés pour les informations sensibles |
WSTG-CONF-05 | Énumérer les interfaces d'administration d'infrastructure et d'application |
WSTG-CONF-06 | Tester les méthodes HTTP |
WSTG-CONF-07 | Tester la sécurité du transport strict HTTP |
WSTG-CONF-08 | Tester la stratégie interdomaine RIA |
WSTG-CONF-09 | Autorisation de fichier de test |
WSTG-CONF-10 | Test de reprise de sous-domaine |
WSTG-CONF-11 | Tester le stockage en nuage |
Test de gestion des identités
Test de gestion des identités | Nom du test |
WSTG-IDNT-01 | Définitions des rôles de test |
WSTG-IDNT-02 | Tester le processus d'enregistrement des utilisateurs |
WSTG-IDNT-03 | Tester le processus de provisionnement de compte |
WSTG-IDNT-04 | Test d'énumération de compte et de compte d'utilisateur devinable |
WSTG-IDNT-05 | Test de la politique de nom d'utilisateur faible ou non appliquée |
Test d'authentification
Test d'authentification | Nom du test |
WSTG-ATHN-01 | Test des informations d'identification transportées sur un canal crypté |
WSTG-ATHN-02 | Test des informations d'identification par défaut |
WSTG-ATHN-03 | Test de mécanisme de verrouillage faible |
WSTG-ATHN-04 | Test de contournement du schéma d'authentification |
WSTG-ATHN-05 | Test de mémorisation du mot de passe vulnérable |
WSTG-ATHN-06 | Test des faiblesses du cache du navigateur |
WSTG-ATHN-07 | Test de la politique de mot de passe faible |
WSTG-ATHN-08 | Test de réponse à la question de sécurité faible |
WSTG-ATHN-09 | Test des fonctionnalités de modification ou de réinitialisation de mot de passe faibles |
WSTG-ATHN-10 | Test d'authentification plus faible dans un canal alternatif |
Test d'autorisation
Test d'autorisation | Nom du test |
WSTG-ATHZ-01 | Test de l'inclusion du fichier de traversée de répertoires |
WSTG-ATHZ-02 | Test du schéma d'autorisation de contournement |
WSTG-ATHZ-03 | Test d'élévation de privilèges |
WSTG-ATHZ-04 | Test des références d'objet directes non sécurisées |
Test de gestion de session
Test de gestion de session | Nom du test |
WSTG-SESS-01 | Test du schéma de gestion de session |
WSTG-SESS-02 | Test des attributs des cookies |
WSTG-SESS-03 | Test de fixation de session |
WSTG-SESS-04 | Test des variables de session exposées |
WSTG-SESS-05 | Test de falsification de requête intersite |
WSTG-SESS-06 | Test de la fonctionnalité de déconnexion |
WSTG-SESS-07 | Expiration de la session de test |
WSTG-SESS-08 | Test de Session Puzzling |
WSTG-SESS-09 | Test de piratage de session |
Test de validation des données
Test de validation des données | Nom du test |
WSTG-INPV-01 | Test des scripts intersites réfléchis |
WSTG-INPV-02 | Test des scripts intersites stockés |
WSTG-INPV-03 | Test de falsification de verbe HTTP |
WSTG-INPV-04 | Test de la pollution des paramètres HTTP |
WSTG-INPV-05 | Test d'injection SQL |
WSTG-INPV-06 | Test d'injection LDAP |
WSTG-INPV-07 | Test d'injection XML |
WSTG-INPV-08 | Test d'injection SSI |
WSTG-INPV-09 | Test d'injection XPath |
WSTG-INPV-10 | Test de l'injection SMTP IMAP |
WSTG-INPV-11 | Test d'injection de code |
WSTG-INPV-12 | Test d'injection de commande |
WSTG-INPV-13 | Test d'injection de chaîne de format |
WSTG-INPV-14 | Test de vulnérabilité incubée |
WSTG-INPV-15 | Test de contrebande de fractionnement HTTP |
WSTG-INPV-16 | Test des requêtes entrantes HTTP |
WSTG-INPV-17 | Test de l'injection d'en-tête d'hôte |
WSTG-INPV-18 | Test d'injection de modèle côté serveur |
WSTG-INPV-19 | Test de falsification de requête côté serveur |
La gestion des erreurs
La gestion des erreurs | Nom du test |
WSTG-ERRH-01 | Test de la gestion incorrecte des erreurs |
WSTG-ERRH-02 | Test des traces de pile |
Cryptographie
Cryptographie | Nom du test |
WSTG-CRYP-01 | Test de sécurité de la couche de transport faible |
WSTG-CRYP-02 | Test de rembourrage Oracle |
WSTG-CRYP-03 | Test des informations sensibles envoyées via des canaux non cryptés |
WSTG-CRYP-04 | Test de chiffrement faible |
Test de la logique métier
Test de la logique métier | Nom du test |
WSTG-BUSL-01 | Tester la validation des données de la logique métier |
WSTG-BUSL-02 | Tester la capacité à falsifier des requêtes |
WSTG-BUSL-03 | Vérifications de l'intégrité des tests |
WSTG-BUSL-04 | Tester la synchronisation du processus |
WSTG-BUSL-05 | Tester le nombre de fois qu'une fonction peut être utilisée Limites |
WSTG-BUSL-06 | Tests de contournement des flux de travail |
WSTG-BUSL-07 | Tester les défenses contre l'utilisation abusive des applications |
WSTG-BUSL-08 | Tester le téléchargement de types de fichiers inattendus |
WSTG-BUSL-09 | Tester le téléchargement de fichiers malveillants |
Test côté client
Test côté client | Nom du test |
WSTG-CLNT-01 | Test des scripts intersites basés sur DOM |
WSTG-CLNT-02 | Tester l'exécution de JavaScript |
WSTG-CLNT-03 | Test d'injection HTML |
WSTG-CLNT-04 | Test de la redirection d'URL côté client |
WSTG-CLNT-05 | Test d'injection CSS |
WSTG-CLNT-06 | Test de la manipulation des ressources côté client |
WSTG-CLNT-07 | Tester le partage des ressources entre les origines |
WSTG-CLNT-08 | Test du clignotement intersite |
WSTG-CLNT-09 | Tester le détournement de clic |
WSTG-CLNT-10 | Tester les WebSockets |
WSTG-CLNT-11 | Tester la messagerie Web |
WSTG-CLNT-12 | Test du stockage du navigateur |
WSTG-CLNT-13 | Test d'inclusion de scripts intersites |
Test d'API
Test d'API | Nom du test |
WSTG-APIT-01 | Tester GraphQL |
Examen du portefeuille crypto
Examen du portefeuille crypto | Nom du test |
SAYFER-CRPTW-01 | Tester la logique commerciale commerciale |
SAYFER-CRPTW-03 | Tester les configurations de nœuds de crypto-monnaie basés sur UTXO |
SAYFER-CRPTW-04 | Tester les configurations de code de crypto-monnaie basées sur le compte |
SAYFER-CRPTW-05 | Tester le code critique de confirmation de transaction |
SAYFER-CRPTW-06 | Tester la prise en charge de TAPROOT |
SAYFER-CRPTW-07 | Tester le stockage de la clé privée |
Commandez l'audit de Sayfer
Résultats de l'évaluation de la sécurité
Enregistrement des clés MPC privées de manière non sécurisée
ID | SAYFER-CRPTW-07 |
Analyse | Haute |
Compétence requise | Haute |
OWASP Référence |
- |
Localisation | - |
Outils | Audit de configuration |
Description
Les échanges centralisés souffrent de pratiques de gestion des clés de mauvaise qualité. Il existe de nombreux exemples de tels cas où les clés ont été perdues ou volées, entraînant la perte par le service de tous les fonds du portefeuille ou le verrouillage complet des fonds.
Lors de notre audit des fichiers de configuration, nous sommes passés en revue le stockage de la gestion des clés. Nous avons constaté que les clés utilisées pour le portefeuille multi-signatures froid ne sont pas stockées dans des emplacements suffisamment distribués.
Il y a 3 clés qui sont utilisées dans la signature de clé MPC. 1 est stocké dans une machine physique protégée. Les 2 autres sont stockés dans la même machine dédiée dans GCP.
Quelques mesures de sécurité ont été prises pour sécuriser ces machines, mais le problème repose sur la distribution. Si la machine déployée sur GCP est compromise, un attaquant peut signer n'importe quelle transaction à partir du portefeuille froid.
Il s'agit d'un endroit à haut risque et sensible où beaucoup ont échoué dans le passé, les meilleures pratiques doivent être strictement suivies.
Atténuation
Utilisez un service de dépositaire tiers pour gérer les portefeuilles chauds et les coffres-forts. Nous nous ferons un plaisir de vous recommander un de nos partenaires.
Ces services gèrent le MPC et la gestion des clés pour vous, avec d'autres couches de sécurité supplémentaires faisant de l'utilisation de ces services le meilleur choix pour les échanges centralisés.
Injection SQL
ID | WSTG-INPV-05 |
Analyse | Haute |
Compétence requise | Moyenne |
OWASP Référence |
- Lien |
Localisation | – ██████████████ |
Outils | Répéteur Burp, sqlmap, PayloadAllTheThings |
Description
Une attaque par injection SQL consiste à insérer ou « injecter » une requête SQL partielle ou complète dans l'entrée de données qui est transmise du client à l'application Web. Une attaque par injection SQL réussie peut lire des données sensibles dans la base de données, modifier les données de la base de données (insérer/mettre à jour/supprimer), effectuer des opérations d'administration de la base de données (telles que l'arrêt du SGBD), récupérer le contenu d'un fichier donné sur le système de fichiers du SGBD ou écrire des fichiers dans le système de fichiers et, dans certains cas, envoyer des commandes au système d'exploitation.
Le transaction
point final, nous avons pu abuser de la more
Paramètre de requête d'URL pour injecter une charge utile SQL malveillante :
/api/transactions?size=10&more=te');INJECTION_PAYLOAD
La charge utile que nous avons utilisée était :
/api/transactions?size=10&sort=time,DESC&more=te');SELECT+CASE+WHEN+(substring(versio n(),12,2)+%3d+'10')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END%3b
– Qui dans ce cas, vérifie si l'instance en cours d'exécution de Postgres est la version 10 ou non.
Un attaquant qui exploite cette vulnérabilité pourrait prendre le contrôle du système. Nous avons pu extraire les schémas de table, mettre à jour le rôle de notre propre utilisateur ou vider toutes les informations enregistrées sur la base de données et même modifier le solde de notre utilisateur sur la base de données.
Atténuation
La vulnérabilité d'injection SQL est facile à corriger mais difficile à atténuer. Un linting fort ou la mise en œuvre de règles de compilation qui imposent les changements futurs sont nécessaires.
L'atténuation des vulnérabilités d'injection SQL est généralement effectuée en suivant un cadre de choix, ce qui signifie que le développeur ne doit jamais concaténer des chaînes dans une instruction SQL complète.
Chaque entrée utilisateur doit être filtrée dans un exécuteur SQL plutôt que d'être utilisée comme une simple chaîne de requête SQL.
Pour plus d'informations sur la perfection de l'injection SQL, veuillez consulter le SQL IAide-mémoire sur la prévention des injections.
Références d'objet directes non sécurisées
ID | WSTG-ATHZ-04 |
Analyse | Haute |
Compétence requise | Moyenne |
OWASP Référence |
- Lien |
Localisation | – ██████████████████/dashboad/{DASHBOARD_ID} |
Outils | Répéteur Burp, DevTools |
Description
Les références d'objet directes non sécurisées (IDOR) sont un type de vulnérabilité de contrôle d'accès qui survient lorsqu'une application utilise une entrée fournie par l'utilisateur pour accéder directement aux objets. En raison de cette vulnérabilité, les attaquants peuvent contourner l'autorisation et accéder directement aux ressources du système, par exemple, les enregistrements ou les fichiers de la base de données.
Nous avons découvert que l'API █████████ permet à un attaquant de voir les informations du tableau de bord d'autres utilisateurs, y compris toutes les données financières de cet utilisateur.
La vulnérabilité repose sur le paramètre d'identification du tableau de bord qui est un entier devinable. Exemple de demande pour un seul tableau de bord (pour un tableau de bord qui n'appartient pas à l'utilisateur actuel) :
GET ████/dashboard/827371 HTTP/1.1
Host: ██████████████████
api-key: ██████████
…
Cela indique que le /dashboard/DASHBOARD_ID
le point de terminaison ne vérifie pas l'autorisation pour la ressource demandée. Un attaquant authentifié pourrait gratter chaque tableau de bord contenant des informations sur les fonds de l'utilisateur et les transactions passées.
Atténuation
Il existe plusieurs façons d'atténuer les vulnérabilités IDOR, dans ce cas, il semble que la solution pourrait être de vérifier l'autorisation pour chaque demande.
Cela signifie que chaque clé de requête ne pourra récupérer que les tableaux de bord de son compte
Authentification plus faible dans le canal alternatif
ID | WSTG-ATHN-10 |
Analyse | Haute |
Compétence requise | Moyenne |
OWASP Référence |
- Lien |
Localisation | – ██████████████████ |
Outils | Google Chrome, DevTools, amasser, ffuf |
Description
Même si les mécanismes d'authentification principaux n'incluent aucune vulnérabilité, il se peut que des vulnérabilités existent dans d'autres canaux d'utilisateurs légitimes d'authentification pour les mêmes comptes d'utilisateurs.
Cette vulnérabilité fait partie d'une chaîne de 2 vulnérabilités qui nous a permis de prendre en charge n'importe quel compte avec juste une adresse e-mail.
Dans le cadre de notre phase de reconnaissance où nous essayons de trouver un vecteur d'attaque plus large en énumérant les principaux sous-systèmes cibles, nous avons trouvé une interface d'administration sous le sous-domaine ██████████████████. Il est possible de se connecter à l'interface d'administration en utilisant un utilisateur normal de l'application, mais pour presque toutes les requêtes réseau que nous avons inspectées lors du chargement de la page principale, le serveur renvoie une erreur 401.
[IMAGE_REDACTED]
Nous avons procédé à une rétro-ingénierie du fichier bundle main.js qui contient le code frontal de l'application et avons trouvé tous les points de terminaison potentiels avec lesquels un administrateur peut interagir.
Nous ne pourrions exploiter que le point final de api/updateUser
. Le point de terminaison nous a permis de modifier n'importe quel e-mail d'utilisateur, et ce faisant, nous avons pu réinitialiser le mot de passe de la victime et reprendre le compte
[IMAGE_REDACTED]
Atténuation
Il est fortement recommandé de mettre en place un mécanisme d'authentification ou un VPN pour le débogage ou pour les services d'administration du système afin d'empêcher la présence d'applications publiques non sécurisées pouvant être exploitées par un attaquant.
De plus, il existe un mécanisme d'autorisation dans l'interface d'administration, mais cela sort du cadre de ce projet.
Examiner les métafichiers du serveur Web pour détecter les fuites d'informations
ID | WSTG-INFO-03 |
Analyse | Haute |
Compétence requise | Moyenne |
OWASP Référence |
- Lien |
Localisation | – ████████████████
– █████████████████████████████ – ████████████ |
Outils | Chrome, vas-y |
Description
Dans le cadre de nos recherches sur la cible et ses sous-domaines, nous avons trouvé des métafichiers qui ne devraient pas être publics, ou du moins pas sans le mécanisme d'authentification approprié.
- ████████████████████████.gitignore
- ██████████████████████████████/docker-compose.yml
- ████████████████████████/swagger-ui.html
[IMAGE_REDACTED]
[IMAGE_REDACTED]
[IMAGE_REDACTED]
Nous avons trouvé trois types de fichiers qui peuvent nuire aux services ████████, .gitignore
, swagger-ui
et par docker-compose.yml
dossier. Ces trois fichiers révèlent des données sensibles
sur l'architecture des services. Un acteur malveillant peut utiliser ces informations pour augmenter son vecteur d'attaque sur la cible.
Atténuation
Si possible, retirez ces fichiers du service public ou mettez en place un mécanisme d'autorisation qui n'accorde l'accès qu'aux utilisateurs privilégiés.
En-tête de politique de sécurité de contenu manquant
ID | SAYFER-CONFIG-008 |
Analyse | Moyenne |
Compétence requise | Haute |
OWASP Référence |
- |
Localisation | - |
Outils | Burp, navigateur Web |
Description
La politique de sécurité du contenu (CSP) est une couche de sécurité supplémentaire qui permet de détecter et d'atténuer certains types d'attaques, notamment les attaques de script intersite (XSS) et d'injection de données.
Nous n'avons trouvé d'en-tête CSP dans aucune des réponses du serveur.
[IMAGE_REDACTED]
En utilisant les administrateurs de sites Web CSP, ils ajoutent une autre ligne de défense contre les attaques XSS ou de détournement de clics, ce faisant, le système sera sécurisé même si de futures modifications non sécurisées sont apportées au code source.
Une politique CSP de base doit au moins décrire les domaines par défaut sur liste blanche pour les fichiers statiques (tels que les scripts, les images et les CSS). Et frame-ancestors
pour empêcher les attaques par détournement de clic.
Plus d'infos:
Atténuation
Ajout du Content-Security-Policy: [policy]
sur chaque réponse où le chargement de ressources externes pourrait être dangereux
Nous vous recommandons vivement de l'utiliser et de le tester d'abord avec la variante "Report-Only" pour tester votre politique avant de la mettre en production :
Content-Security-Policy-Report-Only: [policy]
Test des en-têtes de sécurité
ID | SAYFER-CONFIG-009 |
Analyse | Moyenne |
Compétence requise | Haute |
OWASP Référence |
- |
Localisation | – ████████████ |
Outils | Burp, navigateur Web |
Description
- Les navigateurs prennent en charge de nombreux en-têtes HTTP qui peuvent améliorer la sécurité des applications pour se protéger contre une variété d'attaques courantes, les en-têtes sont échangés entre un client Web (généralement un navigateur) et un serveur pour spécifier les détails liés à la sécurité de la communication HTTP.
En regardant les en-têtes de sécurité de ████████, il manque ce qui suit :
- Options de type de contenu X
Définir cet en-tête empêchera le navigateur d'interpréter les fichiers comme autre chose que ce qui est déclaré par le type de contenu dans les en-têtes HTTP.
- Strict-Transport-Sécurité
HSTS est un mécanisme de politique de sécurité Web qui aide à protéger les sites Web contre les attaques de dégradation de protocole et le détournement de cookies. Il permet aux serveurs Web de déclarer que les navigateurs Web ne doivent interagir avec lui qu'en utilisant des connexions HTTPS sécurisées, et jamais via le protocole HTTP non sécurisé.
- Politique de parrainage
L'en-tête Referer est un en-tête de requête qui indique le site d'où provient le trafic. S'il n'y a pas de prévention adéquate en place, l'URL elle-même, et même les informations sensibles contenues dans l'URL, seront divulguées au site d'origine croisée.
- Contrôle d'accès-Autoriser-Origine
L'en-tête a la valeur "*" qui expose l'API pour chaque site Web, ce n'est peut-être pas le résultat souhaité.
Atténuation
Ajout des en-têtes mentionnés ci-dessus à tous les services back-end.
Examiner les métafichiers du serveur Web pour détecter les fuites d'informations
ID | WSTG-INFO-03 |
Analyse | Faible |
Compétence requise | Moyenne |
OWASP Référence |
- Lien |
Localisation | - |
Outils | Outils de développement |
Description
Lors de la recherche de la cible avec DevTool, nous avons pu afficher le code source frontal sans aucun obscurcissement. Cette vulnérabilité se produit parce que les bundles JS sont livrés avec des cartes source en production, ce qui permet de lire le code source d'origine avec des commentaires susceptibles de révéler des informations, par exemple, le fichier paths.ts suivant :
█████████████████████/paths.ts [IMAGE_REDACTED]
En disposant de la carte source, un attaquant peut en savoir plus sur la base de code, lire les commentaires et trouver des parties de code obsolètes qui peuvent ensuite être utilisées pour trouver des vulnérabilités.
Atténuation
N'expédiez pas les cartes source à la production, la plupart des systèmes de journalisation et de traçage des erreurs sont d'avis de télécharger les cartes source vers un système de back-office. Une autre approche serait de servir les cartes source uniquement aux utilisateurs authentifiés via VPN ou d'autres mécanismes.
Serveur Web d'empreintes digitales
ID | WSTG-INFO-002 |
Analyse | Faible |
Compétence requise | Moyenne |
OWASP Référence |
- Lien |
Localisation | – ███████████████████████████ |
Outils | Rot |
Description
Bien que les informations de serveur exposées ne constituent pas nécessairement une vulnérabilité en elles-mêmes, ce sont des informations qui peuvent aider les attaquants à exploiter d'autres vulnérabilités qui peuvent exister. La plupart des points de terminaison ne divulguent aucune information sur le serveur via des en-têtes HTTP ou des pages d'erreur.
En utilisant la requête HTTP mal formée suivante, nous avons pu identifier un serveur Nginx via une réponse 400
GET /v2 HTTPMALFORMED/1.1
Host: ██████████████████
Accept: */*
Le corps de la réponse est :
<html>
<head><title>400 Bad Request</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx 1.14.0</center>
</body>
</html>
Atténuation
Il existe différentes manières d'obscurcir les en-têtes de serveur Web, les méthodes les plus couramment utilisées sont :
- Serveurs proxy inverses qui se situent entre l'internet mondial et l'interne
- Configurez chaque serveur Web pour supprimer ces en-têtes.
Annexe A : Correctifs d'évaluation de la sécurité
Sera mis à jour par l'équipe Sayfer après la première révision.