Skip to content
GitLab
Next
    • Why GitLab
    • Pricing
    • Contact Sales
    • Explore
  • Why GitLab
  • Pricing
  • Contact Sales
  • Explore
  • Sign in
  • Get free trial
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #354791

Restrict membership by email domain can be by-passed using "Invite a Group" option

HackerOne report #1501733 by muthu_prakash on 2022-03-06, assigned to @dcouture:

Report | Attachments | How To Reproduce

Report

Summary

Gitlab provides an option for Groups where adding new members to the group can be restricted by using the Email domain. We can whitelist domains and members will be restricted if the users Email domain is not under the whitelist configuration.

Restrict Group access by domain wiki

The wiki states that the once domain whitelist is added new members with other domains are restricted from adding into the Groups and it's projects. This check is not implemented properly in "Invite a Group" option. So using the "Invite a Group" option we can by-pass the whitelist domain config and add unauthorised user to the Groups and it's projects.

Steps to reproduce
  1. Create a group in Gitlab. Once group is created add a domain whitelist configuration under
    -> Go to the group’s Settings > General page.
    -> Expand the Permissions and group features section.
    -> In the Restrict membership by email field, enter the domain names. For testing I have added test domains "slack.com" and "test.com"
    ->Select Save changes.

  2. Let us consider this group as "Victim" group.After domain restriction is added we can only invite new members to the group whose Email domains
    matches "slack.com" and "test.com". Members with other domains cannot be added to this group.

  3. Create a new sample Project in Victim group and add some members (who have the whitelist Email domains) into the Project with "Maintainer" Role.
    Now login into the newly added member account. This member account have "Maintainer" role access for the project and can add new members to the
    project. Let us consider this account as "Account2".

  4. Now from "Account2" try to invite a new member to the project whose Email doesn't match the whitelist configuration. It will be restricted.

  5. To by-pass this, from "Account2" create a new group and add some members to the group. Let us consider this group as "Attacker". This attacker group contains members whose email domains are not in "Victim" groups whitelist configuration.
    Victim Group has whitelist domains -> "slack.com" and "test.com"
    Attacker Group have members with Email -> "wearehackerone.com"

  6. Now from "Account2" go the project in Victim group and use the "Invite a Group" option under "Project Information" -> "Members" -> "Invite a Group". Invite the "Attacker" group. Now Attacker group have access to the Project under Victim group. Note that "Victim" group have whitelist domains "slack.com" and "test.com" and the attacker group have members whose Emails are in domains "wearehackerone.com". So the invite a Group option doesn't restrict members from the invited groups for whitelist configuration.

Have added a screen recording demonstrating the issue.

Impact

Whitelist domain configuration is not restricted when using "Invite a Group" option which leads to Project maintainers adding unauthorised members to the Groups Project's.

What is the current bug behavior?

Project maintainers in a Group with whitelist Domain Configuration can add new members using "invite a group" option to the Groups Projects whose Email domains doesn't match the whitelist domain configuration.

What is the expected correct behavior?

Project maintainers in a Group with whitelist Domain Configuration should be restricted from adding new members "invite a group" option to the Groups Projects whose Email domains doesn't match the whitelist domain configuration.

Output of checks

This bug happens on GitLab.com

Results of GitLab environment info

Impact

Whitelist domain configuration is not restricted when using "Invite a Group" option which leads to Project maintainers adding unauthorised members to the Groups Project's.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

  • Screen_Recording_2022-03-05_at_8.30.22_PM.mov

How To Reproduce

Please add reproducibility information to this section:

Edited Apr 28, 2022 by Abdul Wadood
Assignee
Assign to
Time tracking