doc-locale/fr-fr/security/webhooks.md
{{< details >}}
{{< /details >}}
Pour se protéger contre le risque de perte et d'exposition des données, les administrateurs GitLab peuvent désormais utiliser des contrôles de filtrage des requêtes sortantes afin de restreindre certaines requêtes sortantes effectuées par l'instance GitLab.
Les utilisateurs disposant du rôle Maintainer ou Owner peuvent configurer des webhooks déclenchés lorsque des modifications spécifiques surviennent dans un projet ou un groupe. Lorsqu'il est déclenché, une requête HTTP POST est envoyée à une URL. Un webhook est généralement configuré pour envoyer des données à un service web externe spécifique, qui traite les données de manière appropriée.
Cependant, un webhook peut être configuré avec une URL pointant vers un service web interne plutôt qu'un service web externe. Lorsque le webhook est déclenché, des services web non-GitLab s'exécutant sur votre serveur GitLab ou dans son réseau local pourraient être exploités.
Les requêtes de webhook sont effectuées par le serveur GitLab lui-même et utilisent un token secret optionnel unique par hook pour l'autorisation, au lieu de :
Par conséquent, ces requêtes peuvent avoir un accès plus large que prévu, notamment l'accès à tout ce qui s'exécute sur le serveur hébergeant le webhook, y compris :
Les webhooks peuvent être utilisés pour déclencher des commandes destructives à l'aide de services web qui ne nécessitent pas d'authentification. Ces webhooks peuvent amener le serveur GitLab à effectuer des requêtes HTTP POST vers des points de terminaison qui suppriment des ressources.
Prérequis :
Pour prévenir l'exploitation de services web internes non sécurisés, toutes les requêtes de webhook et d'intégration vers les adresses réseau local suivantes ne sont pas autorisées :
127.0.0.1, ::1, 0.0.0.0, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, et les adresses IPv6 site-local (ffc0::/10).Pour autoriser l'accès à ces adresses :
Prérequis :
Les crochets système peuvent effectuer des requêtes vers le réseau local par défaut. Pour empêcher les requêtes des crochets système vers le réseau local :
Prérequis :
Le DNS rebinding est une technique permettant de faire résoudre un nom de domaine malveillant vers une ressource de réseau interne afin de contourner les restrictions d'accès au réseau local. GitLab dispose d'une protection contre cette attaque activée par défaut. Pour désactiver cette protection :
{{< history >}}
{{< /history >}}
Prérequis :
Pour filtrer les requêtes en bloquant de nombreuses requêtes :
Lorsque cette case est cochée, les requêtes vers les éléments suivants ne sont toujours pas bloquées :
Lorsque ce paramètre est activé, GitLab peut effectuer une résolution DNS sur les URL incluses dans d'autres objets, tels que les liens de release. Si la résolution DNS échoue, la requête échoue. Pour résoudre ce problème, ajoutez le nom d'hôte à la liste des permissions, même si GitLab n'a jamais besoin d'établir une connexion sortante vers cet hôte.
Ce paramètre est respecté uniquement par l'application principale GitLab ; d'autres services comme Gitaly peuvent donc toujours effectuer des requêtes qui enfreignent la règle. De plus, certaines zones de GitLab ne respectent pas les règles de filtrage des requêtes sortantes.
Prérequis :
Pour autoriser les requêtes sortantes vers certaines adresses IP et certains domaines :
Les entrées peuvent :
127.0.0.1:8080 autorise uniquement les connexions au port 8080 sur 127.0.0.1. Si aucun port n'est spécifié, tous les ports de cette adresse IP ou de ce domaine sont autorisés. Une plage d'adresses IP autorise tous les ports sur toutes les adresses IP de cette plage.*.example.com).Par exemple :
example.com;gitlab.example.com
127.0.0.1,1:0:0:0:0:0:0:1
127.0.0.0/8 1:0:0:0:0:0:0:0/124
[1:0:0:0:0:0:0:1]:8080
127.0.0.1:8080
example.com:8080
Lors du filtrage des requêtes sortantes, vous pouvez rencontrer les problèmes suivants.
Vous pouvez cocher la case Bloquer toutes les requêtes à l'exception de celles pour les adresses IP, les plages IP et les noms de domaine définis dans la liste des permissions uniquement si aucune URL configurée ne serait bloquée. Sinon, vous pourriez recevoir un message d'erreur indiquant que l'URL est bloquée.
Si vous ne pouvez pas activer ce paramètre, effectuez l'une des opérations suivantes :
La plupart des instances GitLab ont leur public_runner_releases_url défini sur https://gitlab.com/api/v4/projects/gitlab-org%2Fgitlab-runner/releases, ce qui peut vous empêcher de filtrer les requêtes.
Pour résoudre ce problème, configurez GitLab pour qu'il ne récupère plus les données de version des releases de runner depuis GitLab.com.
Lorsque vous filtrez les requêtes, la gestion des abonnements GitLab est bloquée.
Pour contourner ce problème, ajoutez customers.gitlab.com:443 à la liste des permissions.
Lorsque vous filtrez les requêtes, vous pourriez obtenir une erreur indiquant Help page documentation base url is blocked: Requests to hosts and IP addresses not on the Allow List are denied. Pour contourner cette erreur :
Help page documentation base url is blocked n'apparaisse plus.docs.gitlab.com ou l'URL de redirection des pages d'aide de la documentation à la liste des permissions.Lorsque vous filtrez les requêtes, vous pourriez voir des erreurs 401 en essayant d'utiliser les fonctionnalités GitLab Duo.
Cette erreur peut survenir lorsque les requêtes sortantes vers le serveur cloud GitLab ne sont pas autorisées. Pour contourner cette erreur :
https://cloud.gitlab.com:443 à la liste des permissions.