GitLab FOSS issueshttps://gitlab.com/gitlab-org/gitlab-foss/-/issues2019-09-25T09:05:47Zhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/67387Improve token related documentation2019-09-25T09:05:47ZChristian CouderImprove token related documentation### Problem to solve
In `doc/user/profile/personal_access_tokens.md` we don't provide examples how to use the token.
https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31519 tried to do that, but as this has some security implica...### Problem to solve
In `doc/user/profile/personal_access_tokens.md` we don't provide examples how to use the token.
https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/31519 tried to do that, but as this has some security implications, a security engineer got involved and suggested not to document the insecure capability, but rather stick to Personal Access Token usage for API calls via the `Private-Token` [header](https://docs.gitlab.com/ee/api/README.html#personal-access-tokens). The contributor didn't like that and closed the MR.
I think we should still be able to improve on the current documentation though.
### Proposal
These ideas come from the above MR.
For example just adding a warning to say that the feature is insecure would already be an improvement in my opinion.
GitHub on their ["Git automation with OAuth tokens" page](https://help.github.com/en/articles/git-automation-with-oauth-tokens) has the following warning at the bottom of the page:
`Warning: Tokens have read/write access and should be treated like passwords. If you enter your token into the clone URL when cloning or adding a remote, Git writes it to your .git/config file in plain text, which is a security risk.`
We could perhaps talk about using a git credential helper and configuring it so that the token is stored encrypted, as described in https://stackoverflow.com/questions/53305965/whats-the-best-encrypted-git-credential-helper-for-linux too.
Suggesting in the doc that users rather stick to Personal Access Token usage for API calls via the `Private-Token` [header](https://docs.gitlab.com/ee/api/README.html#personal-access-tokens) would also be an improvement.
### Who can address the issue
My opinion is that this issue would be best addressed if @gitlab-com/gl-security/appsec could collaborate with documentation specialists.
/cc @marcel.amiraulthttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/67109Project Template functionality can be used to copy private project data, such...2023-04-26T17:25:45ZGitLab SecurityBotProject Template functionality can be used to copy private project data, such as repository, confidential issues, snippets, and merge requests**[HackerOne report #689314](https://hackerone.com/reports/689314)** by `jobert` on 2019-09-06, assigned to `jmatos_bgtvf`:
I've found a three minor vulnerabilities which, when combined, allow an attacker to copy private repositories, c...**[HackerOne report #689314](https://hackerone.com/reports/689314)** by `jobert` on 2019-09-06, assigned to `jmatos_bgtvf`:
I've found a three minor vulnerabilities which, when combined, allow an attacker to copy private repositories, confidential issues, private snippets, and then some. I'll go through the code path to explain the vulnerabilities and how they are combined. See the **Proof of Concept** section if you want to reproduce it immediately.
Let's start at the `ProjectsController` of EE, which is prepended to `app/controllers/projects_controller.rb` in an EE instance.
**ee/app/controllers/ee/projects_controller.rb**
```ruby
override :project_params_attributes
def project_params_attributes
super + project_params_ee
end
def project_params_ee
attrs = %i[
# ...
use_custom_template
# ...
group_with_project_templates_id
]
# ...
attrs
end
```
This method defines what parameters can be passed by the user. The two notable parameters here are `use_custom_template` and `group_with_project_templates_id`. This method appends the result value of `project_params_attributes` method in `app/controllers/projects_controller.rb` on line 351, which specifies all the CE attributes a user can provide when creating a project. The CE controller allows the `template_name` parameter to be passed, too. This means that these three parameters can be passed to the `Projects::CreateService` in the `create` method:
**app/controllers/projects_controller.rb**
```ruby
def create
@project = ::Projects::CreateService.new(current_user, project_params(attributes: project_params_create_attributes)).execute
# ...
end
# ...
def project_params_attributes
[
# ...
:template_name,
# ...
]
```
In EE, the `EE:Projects::CreateService` is prepended to the `Projects::CreateService`. The prepended EE code contains logic to validate the `use_custom_template` and `group_with_project_templates_id` parameters.
**ee/app/services/ee/projects/create_service.rb**
```ruby
def execute
# ...
group_with_project_templates_id = params.delete(:group_with_project_templates_id) if params[:template_name].blank?
# ...
validate_namespace_used_with_template(project, group_with_project_templates_id)
end
# ...
def validate_namespace_used_with_template(project, group_with_project_templates_id)
return unless project.group
subgroup_with_templates_id = group_with_project_templates_id || params[:group_with_project_templates_id]
return if subgroup_with_templates_id.blank?
templates_owner = ::Group.find(subgroup_with_templates_id).parent
unless templates_owner.self_and_descendants.exists?(id: project.namespace_id)
project.errors.add(:namespace, _("is not a descendant of the Group owning the template"))
end
end
```
The code above is where the first vulnerability can be found. In a normal situation, a Project Template can only be copied to a namespace (group) that is a descendant of the project template. However, the `validate_namespace_used_with_template` method returns a `nil` value when the project is **not** being created for a group (`return unless project.group`). This means that if a `group_with_project_templates_id` is given for a project that is created in a `User` namespace, the authorization / validation logic is never executed. This means that the `use_custom_template` and `group_with_project_templates_id` parameters remain to be set on the instance variable `params`.
Because the EE code is prepended, the `execute` method is executed before the `Projects::CreateService` is called. Because the EE class its validation logic is bypassed, the `execute` method of the `Projects::CreateService` class is called:
**app/services/projects/create_service.rb**
```ruby
def execute
if @params[:template_name].present?
return ::Projects::CreateFromTemplateService.new(current_user, params).execute
end
# ...
end
```
When a `template_name` is given, instead of executing the normal execution flow, the result of `Projects::CreateFromTemplateService` is returned. The CE code for this class isn't very important. The EE class contains the logic that is worth checking out:
**ee/app/services/ee/projects/create_from_template_service.rb**
```ruby
def execute
return super unless use_custom_template?
override_params = params.dup
params[:custom_template] = template_project if template_project
::Projects::GitlabProjectsImportService.new(current_user, params, override_params).execute
end
private
def use_custom_template?
# ...
template_name &&
::Gitlab::Utils.to_boolean(params.delete(:use_custom_template)) &&
::Gitlab::CurrentSettings.custom_project_templates_enabled?
# ...
end
def template_project
# ...
current_user.available_custom_project_templates(search: template_name, subgroup_id: subgroup_id)
.first
# ...
end
def subgroup_id
params[:group_with_project_templates_id].presence
end
```
This class does a couple of things: it makes sure a custom template name is given, that it should use the given template name, and that the GitLab instance has custom project templates enabled. For what it's worth: gitlab.com has this setting enabled. When it passes those checks, the `template_project` method is invoked. Here is the definition of the `available_custom_project_templates` method:
**ee/app/models/ee/user.rb**
```ruby
def available_custom_project_templates(search: nil, subgroup_id: nil)
templates = ::Gitlab::CurrentSettings.available_custom_project_templates(subgroup_id)
::ProjectsFinder.new(current_user: self,
project_ids_relation: templates,
params: { search: search, sort: 'name_asc' })
.execute
end
```
This method requires two parameters: `search` and `subgroup_id`. The first one is the `template_name` the user passes, the second one `group_with_project_templates_id`. The `templates` variable gets its value based on the following method definition:
**ee/app/models/ee/application_setting.rb**
```ruby
def available_custom_project_templates(subgroup_id = nil)
group_id = subgroup_id || custom_project_templates_group_id
return ::Project.none unless group_id
::Project.where(namespace_id: group_id)
end
```
This method will return all `Project` models based on the `namespace_id` that is provided in the `subgroup_id` parameter. This is then passed to the `ProjectsFinder` in the `available_custom_project_templates` method on the `User` model. This is where the second vulnerability can be found. The `ProjectsFinder` uses an initial collection, which consists of the projects the authenticated user can access. However, it does **not** check the access level of the user. This means that any project that is public, but has Repository, Issue, Snippets (etc.) access disabled for Guests, will be returned by the `available_custom_project_templates` method on the `User` model. In a perfect world, it seems that this method would limit the projects that can be returned based on the user's permissions for said projects.
If we go back to the `EE:Projects::CreateFromTemplateService` file, you can see that the `template_project` will return the first project that is returned by the `available_custom_project_templates` method. This means that `params[:custom_template]` may contain a `Project` model that the user is not authorized to see everything for. The `EE::Projects::CreateFromTemplateService` class then calls the `Projects::GitlabProjectsImportService` class with the updated parameters.
**ee/app/services/ee/projects/gitlab_projects_import_service.rb**
```ruby
def execute
super.tap do |project|
if project.saved? && custom_template
custom_template.add_export_job(current_user: current_user,
after_export_strategy: export_strategy(project))
end
end
end
private
override :prepare_import_params
def prepare_import_params
super
if custom_template
params[:import_type] = 'gitlab_custom_project_template'
end
end
def custom_template
strong_memoize(:custom_template) do
params.delete(:custom_template)
end
end
def export_strategy(project)
Gitlab::ImportExport::AfterExportStrategies::CustomTemplateExportImportStrategy.new(export_into_project_id: project.id)
end
```
This EE class is prepended, but uses `super.tap` to call the CE code (`super`) and then taps into the result of the CE code. If `params[:custom_template]` has been set and the project was successfully saved by the `super` call, an export job is scheduled for the `custom_template` that was returned by the `ProjectsFinder`. It's worth nothing that at this point the user may not be authorized to see the code, issues, etc., of the project. Additionally, an export strategy is passed that imports the export file in the newly created project.
This is where the third vulnerability can be found. When an export job is scheduled, it assumes the user is authorized to make the export. Ideally, the Sidekiq job (`ProjectExportWorker`) that is scheduled would do an authorization check to make sure that the user is authorized to export the project. This would also avoid a TOCTOU issue where the user schedules a job when the queue is clogged / Sidekiq workers are paused and would leave the project before the job is executed. When the export is created, it'll automatically be imported in the project that the user has full access to.
Combined, these vulnerabilities results in an attacker being able to obtain any confidential information that is included in a project export. This vulnerability **only** works for public projects with limited access levels for repositories, issues, pipelines, merge requests (and more) that belong to a group. A good example of this would be `gitlab-org`, `gitlab-data`, `gitlab-com`, on gitlab.com. There are plenty of repositories, such as https://gitlab.com/gitlab-com/finance (see below), that are public but don't expose the repository, issues, and merge requests.
![Screen_Shot_2019-09-05_at_10.08.18_PM.png](https://h1.sec.gitlab.net/a/9ad97b76-4e02-4660-8563-ad3f37695913/Screen_Shot_2019-09-05_at_10.08.18_PM.png)
# Proof of Concept
To reproduce this vulnerability:
* sign in as a normal user and create a group, let's assume this is group ID 1
* within this group, create a public project named `test_project`
* under **Settings > General** update the **Visibility, project features, permissions** to only allow Issues, Repository, Wiki, and Snippets to be seen by **Only Project Members**:
![Screen_Shot_2019-09-05_at_10.13.21_PM.png](https://h1.sec.gitlab.net/a/1f8bcd66-70dd-48d5-a98b-b6c229339a36/Screen_Shot_2019-09-05_at_10.13.21_PM.png)
* sign into another account and go to http://instance/projects/new
* create a new project and intercept the request, it'll look something like this (I've left out unimportant parameters):
```
POST /projects HTTP/1.1
Host: instance
...
----------506740453
Content-Disposition: form-data; name="project[use_custom_template]"
false
----------506740453
Content-Disposition: form-data; name="project[template_name]"
----------506740453
Content-Disposition: form-data; name="project[group_with_project_templates_id]"
----------506740453
Content-Disposition: form-data; name="project[name]"
project_name
----------506740453
Content-Disposition: form-data; name="project[namespace_id]"
1
----------506740453
Content-Disposition: form-data; name="project[path]"
project_name
----------506740453--
```
* in this request, change `use_custom_template` to `true`, the `template_name` to the name the victim gave to the project (`test_project`), and `group_with_project_templates_id` to the group ID of the public group the victim created (`1`). When forwarded, the server will respond with a redirect and, when followed, show a page indicating that the project is being imported:
![Screen_Shot_2019-09-05_at_10.17.09_PM.png](https://h1.sec.gitlab.net/a/d773494e-849e-4e55-b12b-70c9ffe3cd58/Screen_Shot_2019-09-05_at_10.17.09_PM.png)
Depending on the size of the project and how busy the queues are, it can take a couple of minutes to generate the export of the project and then import it to the new project. Come back in a couple minutes and find the repository, confidential issues, private snippets, merge requests, CI pipelines, and more being copied to the attacker's project.
**Redacted copy of `gitlab-com/finance`**
![Screen_Shot_2019-09-05_at_10.19.15_PM.png](https://h1.sec.gitlab.net/a/43ccd1ab-46c6-4027-9527-fc2766e37834/Screen_Shot_2019-09-05_at_10.19.15_PM.png)
## Impact
Any access level that has been put in place for projects the user can access can be bypassed using this vulnerability. According to the documentation, this means that the following information can be obtained:
* Project and wiki repositories
* Project uploads
* Project configuration, including services
* Issues with comments, merge requests with diffs and comments, labels, milestones, snippets, and other project entities
* LFS objects
* Issue Boards
![cat.gif](https://h1.sec.gitlab.net/a/93b0192e-5a07-409f-8336-3c0e563293d9/cat.gif)
## Attachments
**Warning:** Attachments received through HackerOne, please exercise caution!
* [Screen_Shot_2019-09-05_at_10.08.18_PM.png](https://h1.sec.gitlab.net/a/9ad97b76-4e02-4660-8563-ad3f37695913/Screen_Shot_2019-09-05_at_10.08.18_PM.png)
* [Screen_Shot_2019-09-05_at_10.13.21_PM.png](https://h1.sec.gitlab.net/a/1f8bcd66-70dd-48d5-a98b-b6c229339a36/Screen_Shot_2019-09-05_at_10.13.21_PM.png)
* [Screen_Shot_2019-09-05_at_10.17.09_PM.png](https://h1.sec.gitlab.net/a/d773494e-849e-4e55-b12b-70c9ffe3cd58/Screen_Shot_2019-09-05_at_10.17.09_PM.png)
* [Screen_Shot_2019-09-05_at_10.19.15_PM.png](https://h1.sec.gitlab.net/a/43ccd1ab-46c6-4027-9527-fc2766e37834/Screen_Shot_2019-09-05_at_10.19.15_PM.png)
* [cat.gif](https://h1.sec.gitlab.net/a/93b0192e-5a07-409f-8336-3c0e563293d9/cat.gif)12.3George KoltsovGeorge Koltsovhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/66172GitHub project integration form does not need to display stored personal acce...2019-08-23T22:19:50ZKaroline PaulsGitHub project integration form does not need to display stored personal access token to the userWhile the token theoretically should only have very limited permissions, practice shows the is oftentimes very much not the case. GitLab can do a better job of protecting users from their own ingenuity by masking the token or a part ther...While the token theoretically should only have very limited permissions, practice shows the is oftentimes very much not the case. GitLab can do a better job of protecting users from their own ingenuity by masking the token or a part thereof.
It would also be nice to be able to reuse the GitHub repository mirroring token, since it needs to be used anyway.
![gitlab-github-project-integration-plaintext](/uploads/f2b678b36db7153c6c83cf4d4ba0f272/gitlab-github-project-integration-plaintext.png)https://gitlab.com/gitlab-org/gitlab-foss/-/issues/65671Update mini_magick to 4.9.5 (CVE-2019-13574)2019-09-25T03:58:39ZTakuya NoguchiUpdate mini_magick to 4.9.5 (CVE-2019-13574)Updates mini_magick from 4.8.0 to 4.9.5 to address CVE-2019-13574 (CVE v3 7.5).
### upstream diff
- https://github.com/minimagick/minimagick/compare/v4.8.0...v4.9.5
### CVEs
- https://github.com/rubysec/ruby-advisory-db/blob/master/g...Updates mini_magick from 4.8.0 to 4.9.5 to address CVE-2019-13574 (CVE v3 7.5).
### upstream diff
- https://github.com/minimagick/minimagick/compare/v4.8.0...v4.9.5
### CVEs
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/mini_magick/CVE-2019-13574.yml12.2Takuya NoguchiTakuya Noguchi2019-08-07https://gitlab.com/gitlab-org/gitlab-foss/-/issues/65337Security Release: 12.2.3, 12.1.8, and 12.0.82019-10-01T08:32:58ZJeremy MatosSecurity Release: 12.2.3, 12.1.8, and 12.0.8## Releases tasks
- https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/release-manager.md
- https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md
- https://gitlab.com/gitlab-org/releas...## Releases tasks
- https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/release-manager.md
- https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md
- https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/security-engineer.md
## Version issues:
* 12.2.3: https://gitlab.com/gitlab-org/release/tasks/issues/931
* 12.1.8: https://gitlab.com/gitlab-org/release/tasks/issues/928
* 12.0.8: https://gitlab.com/gitlab-org/release/tasks/issues/929
## Security Issues:
### CE
* {https://gitlab.com/gitlab-org/gitlab-ce/issues link}
* https://gitlab.com/gitlab-org/gitlab-ce/issues/61314
* https://gitlab.com/gitlab-org/gitlab-ce/issues/59549
* https://gitlab.com/gitlab-org/gitlab-ee/issues/11302
* https://gitlab.com/gitlab-org/gitlab-ce/issues/55115
* https://gitlab.com/gitlab-org/gitaly/1877
### EE
* {https://gitlab.com/gitlab-org/gitlab-ee/issues link}
### Omnibus-GitLab
* https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4380
* https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4241
## Security Issues in dev.gitlab.org:
### CE
- {https://dev.gitlab.org/gitlab/gitlabhq/issues link}
| Version | MR |
|---------|----|
| 12.2 | {https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/ link} |
| 12.1 | {https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/ link} |
| 12.0 | {https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/ link} |
| master | {https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/ link} |
- https://dev.gitlab.org/gitlab/gitlabhq/issues/2882
| Description | Link |
| -------- | -------- |
| Original issue | https://gitlab.com/gitlab-org/gitlab-ce/issues/61314 |
| Security release issue | https://gitlab.com/gitlab-org/gitlab-ce/issues/65337 |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3345 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1188 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3268 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1132 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3289 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3290 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1141 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1142 |
- https://dev.gitlab.org/gitlab/gitlabhq/issues/2883
| Version | MR |
| -------- | -------- |
| `12.3` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3270 |
| `12.3` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1148 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3349 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3295 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3296 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1189 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1149 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1150 |
- https://dev.gitlab.org/gitlab/gitlabhq/issues/2884
| Version | MR |
|---------|----|
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3277 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1138 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3353 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3287 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3288 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1197 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1139 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1140 |
- https://dev.gitlab.org/gitlab/gitlabhq/issues/2885 @drewcimino
| Version | MR |
| -------- | -------- |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3274 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1128 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3322 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3278 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3279 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1172 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1129 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1130 |
- https://dev.gitlab.org/gitlab/gitlabhq/issues/2894 @drewcimino
| Version | MR |
|---------|----|
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3325 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1213 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3362 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3363 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3364 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1214 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1215 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1216 |
- https://dev.gitlab.org/gitlab/gitlabhq/issues/2895 @drewcimino
| Version | MR |
|---------|----|
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3329 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1203 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3354 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3355 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3356 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1204 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1205 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1206 |
- https://dev.gitlab.org/gitlab/gitlabhq/issues/2812
| Version | MR |
| -------- | -------- |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/2926 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1068 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3333 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3231 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3192 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1180 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1069 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1070 |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2880
| Version | MR |
| -------- | -------- |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3250 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1100 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3315 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3298 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3256 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1167 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1152 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1114 |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2886
| Description | Link |
| -------- | -------- |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3266 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1163 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3338 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3311 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3312 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1181 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1165 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1164 |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2875
| Description | Link |
| -------- | -------- |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3224 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1057 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3314 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3310 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3242 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1166 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1162 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1094 |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2898
| Description | Link |
| -------- | -------- |
| `Backport 12.2` MR | Improvement is already in 12.2 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3336 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3335 |
| `Backport 12.2` MR (EE) | Improvement is already in 12.2 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1179 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1178 |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2892
| Description | Link |
| -------- | -------- |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3306 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1174 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3330 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3331 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3332 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1175 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1176 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1177 |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2853
| Description | Link |
| -------- | -------- |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3137 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/966 |
| `backport` MR `12.2` | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3324 |
| `backport` MR `12.1` | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3307 |
| `backport` MR `12.0` | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3308 |
| `backport` MR `11.11` | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3309 |
| `backport` MR (EE) `12.2` | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1183 |
| `backport` MR (EE) `12.1` | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1159 |
| `backport` MR (EE) `12.0` | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1160 |
| `backport` MR (EE) `11.11` | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1161 |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2900
| Description | Link |
| -------- | -------- |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3313 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1198 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3350 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3351 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3352 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1199 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1200 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1201 |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2897
| Description | Link |
| -------- | -------- |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3334 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1193 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3346 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3347 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3348 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1196 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1195 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1194 |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2904
| Description | Link |
| -------- | -------- |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3361 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1219 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3365 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3366 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3367 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1220 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1221 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1222 |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2896
| Description | Link |
| -------- | -------- |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3340 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1217 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3370 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3368 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3369 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1218 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1224 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1223 |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2876
** Note ** that the fix for this issue consists of two MRs - for workhorse and for rails
| Description | Link |
| -------- | -------- |
| `master` MR | https://dev.gitlab.org/gitlab/gitlab-workhorse/merge_requests/20 (workhorse) and https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3226 (rails) |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-workhorse/merge_requests/20 (workhorse) and https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1208 (rails) |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlab-workhorse/merge_requests/21 (workhorse) and https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3359 (rails) |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlab-workhorse/merge_requests/22 (workhorse) and https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3358 (rails) |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlab-workhorse/merge_requests/22 (workhorse) and https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3357 (rails) |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-workhorse/merge_requests/21 (workhorse) and https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1211 (rails) |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-workhorse/merge_requests/22 (workhorse) and https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1210 (rails) |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-workhorse/merge_requests/22 (workhorse) and https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1209 (rails) |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2907
| Description | Link |
| -------- | -------- |
| Original issue | https://gitlab.com/gitlab-org/gitaly/issues/1877 |
| Security release issue | https://gitlab.com/gitlab-org/gitlab-ce/issues/65337 |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3373 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1226 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3374 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1227 |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2901
| Description | Link |
| -------- | -------- |
| Original issue | https://gitlab.com/gitlab-org/gitlab-ce/issues/61210 |
| Security release issue | https://gitlab.com/gitlab-org/gitlab-ce/issues/65337 |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3344 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1235 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3382 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1237 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3383 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1237 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3384 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1238 |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2908
| Description | Link |
| -------- | -------- |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3390 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3389 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3388 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1246 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1245 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1244 |
### EE
* {https://dev.gitlab.org/gitlab/gitlabhq/issues/ link}
| Version | MR |
|---------|----|
| 12.2| {https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/ link} |
| 12.1 | {https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/ link} |
| 12.0 | {https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/ link} |
| master | {https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/ link} |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2899
| Description | Link |
| -------- | -------- |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1184 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1190 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1191 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1192 |
* https://dev.gitlab.org/gitlab/gitlab-ee/issues/376
| Description | Link |
| -------- | -------- |
| `master` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3339 |
| `master` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1182 |
| `Backport 12.2` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3343 |
| `Backport 12.1` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3342 |
| `Backport 12.0` MR | https://dev.gitlab.org/gitlab/gitlabhq/merge_requests/3341 |
| `Backport 12.2` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1187 |
| `Backport 12.1` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1186 |
| `Backport 12.0` MR (EE) | https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1185 |
### Omnibus-GitLab
* https://dev.gitlab.org/gitlab/omnibus-gitlab/issues/40
| Version | MR |
|---------|----|
| `master` MR | https://dev.gitlab.org/gitlab/omnibus-gitlab/merge_requests/125 |
| `backport` MR `12.2` | https://dev.gitlab.org/gitlab/omnibus-gitlab/merge_requests/135 |
| `backport` MR `12.1` | https://dev.gitlab.org/gitlab/omnibus-gitlab/merge_requests/133 |
| `backport` MR `12.0` | https://dev.gitlab.org/gitlab/omnibus-gitlab/merge_requests/131 |
| `backport` MR (EE) `12.1` | https://dev.gitlab.org/gitlab/omnibus-gitlab/merge_requests/134 |
| `backport` MR (EE) `12.0` | https://dev.gitlab.org/gitlab/omnibus-gitlab/merge_requests/132 |
* https://dev.gitlab.org/gitlab/gitlabhq/issues/2902
| Version | MR |
|---------|----|
| `master` MR | https://dev.gitlab.org/gitlab/omnibus-gitlab/merge_requests/136 |
| `backport` MR `12.2` | https://dev.gitlab.org/gitlab/omnibus-gitlab/merge_requests/139 |
| `backport` MR `12.1` | https://dev.gitlab.org/gitlab/omnibus-gitlab/merge_requests/138 |
| `backport` MR `12.0` | https://dev.gitlab.org/gitlab/omnibus-gitlab/merge_requests/137 |
## QA
{QA issue link}
## Blog post
Dev: https://dev.gitlab.org/gitlab/www-gitlab-com/merge_requests/68<br/>
gitlab.com: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/29020
## Email notification
https://gitlab.com/gitlab-com/gl-security/security-communications/communications/issues/111John SkarbekJuan BroullonAndrew KellyJohn Skarbekhttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/65330Use nonce-based Content Security Policy for inline JavaScript2019-12-13T00:26:59ZStan HuUse nonce-based Content Security Policy for inline JavaScriptUsing nonce-based CSP rules may eliminate a significant number of XSS vulnerabilities we have on GitLab.com. We should consider prioritizing this because implementing this could save us a lot of money and headaches from all these HackerO...Using nonce-based CSP rules may eliminate a significant number of XSS vulnerabilities we have on GitLab.com. We should consider prioritizing this because implementing this could save us a lot of money and headaches from all these HackerOne reports.
Right now we have some inline JavaScript left over:
```
$ git grep ":javascript" app
app/views/layouts/_google_analytics.html.haml::javascript
app/views/layouts/_init_auto_complete.html.haml: :javascript
app/views/layouts/_init_client_detection_flags.html.haml: :javascript
app/views/layouts/_piwik.html.haml::javascript
app/views/layouts/errors.html.haml: :javascript
app/views/layouts/group.html.haml: :javascript
app/views/layouts/project.html.haml: :javascript
app/views/layouts/snippets.html.haml: :javascript
app/views/projects/merge_requests/show.html.haml: :javascript
```
Because of this, our CSP rules allow inline JavaScript, but perhaps we can lock this down by using `strict-dynamic` and nonce-based CSP:
* https://engineering.gusto.com/nonce-based-content-security-policy-csp-in-rails/
Rails 5.2 and the `secure_headers` gem supports this. Right now our HAproxy config has these CSP rules, but we should consider pushing these down to the application. We should consider:
1. Allow configuration of CSP rules within GitLab application settings (maybe `gitlab.yml` would be better for version control?)
1. Add a HAML filter for `:securejavascript` or something of the sort: https://github.com/haml/haml/issues/934
1. Change all `:javascript` filters to `:securejavascript`
1. Remove CSP rules from HAproxy
Ideally we'd remove inline JavaScript entirely, but that may not be simple.
Previous references:
* https://gitlab.com/gitlab-org/gitlab-ce/issues/18231https://gitlab.com/gitlab-org/gitlab-foss/-/issues/65195Explicitly tell the User who they are authenticating with in Visual Review To...2019-08-12T14:04:50ZPaul Slaughterpslaughter@gitlab.comExplicitly tell the User who they are authenticating with in Visual Review Toolbar(Identified in [this discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30481#note_196386164))
## Problem to Solve
When entering the personal access token in the Visual Review Toolbar, it is not obvious with whom the us...(Identified in [this discussion](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/30481#note_196386164))
## Problem to Solve
When entering the personal access token in the Visual Review Toolbar, it is not obvious with whom the user is actually authenticating. The dialog looks like GitLab, and an unwary user might think they are authenticating with GitLab, but in reality they are authenticating with the review app (which could gain access to the token).
## Proposal
Let's add a "XYZ is requesting access to your GitLab account" message, similar to those seen in OAuth apps.
**Inspiration:**
| Twitter | GitLab |
|---------|--------|
| ![Screen_Shot_2019-07-27_at_8.29.25_AM](/uploads/a6b45b7443ac852d674b7a22927fa9d7/Screen_Shot_2019-07-27_at_8.29.25_AM.png) | ![Screen_Shot_2019-07-27_at_8.29.55_AM](/uploads/ec7cef70d6c9abba8ed8749669e41ee1/Screen_Shot_2019-07-27_at_8.29.55_AM.png) |
**Mock up:**
![Screen_Shot_2019-07-27_at_8.39.00_AM](/uploads/20a16ece02f5211634b0493a224553eb/Screen_Shot_2019-07-27_at_8.39.00_AM.png)Dimitrie HoekstraDimitrie Hoekstrahttps://gitlab.com/gitlab-org/gitlab-foss/-/issues/64711Attacker is able to access Commit ID, Team Member name and comments when dire...2019-10-01T09:28:38ZGitLab SecurityBotAttacker is able to access Commit ID, Team Member name and comments when directly addressed**[HackerOne report #645412](https://hackerone.com/reports/645412)** by `brijeshshah13` on 2019-07-16, assigned to `akelly`:
### Steps to reproduce
Let's say there are two accounts:
- victim@gmail.com
- attacker@gmail.com
1. Creat...**[HackerOne report #645412](https://hackerone.com/reports/645412)** by `brijeshshah13` on 2019-07-16, assigned to `akelly`:
### Steps to reproduce
Let's say there are two accounts:
- victim@gmail.com
- attacker@gmail.com
1. Create a project from account victim@gmail.com with the following permissions:
![permissions.png](https://h1.sec.gitlab.net/a/0bac3260-7dcd-4090-bdee-819c95fd4c3e/permissions.png)
Note that the project visibility should be `internal`.
2. Go to profile of victim@gmail.com from attacker@gmail.com and subscribe to all events, like this:
![subscribe.png](https://h1.sec.gitlab.net/a/0dad6348-5cfc-4e97-a52f-35de8f2241dc/subscribe.png)
3. From victim account, comment or start a thread on any commit directly addressing the attacker using `@` sign followed by the username, and you should receive it's notification on To-Do List on Gitlab of attacker@gmail.com, like this:
Victim's comment or thread message:
![comment.png](https://h1.sec.gitlab.net/a/765b9ae8-0fa3-444f-991f-b96f258796b0/comment.png)
Attacker's Todo List on GitLab:
![todo.png](https://h1.sec.gitlab.net/a/5e0da15c-8582-48b4-83ae-d206ef14cb41/todo.png)
As seen from the above screenshots, an attacker has easy access to Team member who commented, Commit ID and the comment itself even though the attacker is not a project member. Please let me know if you need more info.
Best Regards,
Brijesh.
## Impact
An attacker will be able to view Team member name, Commit ID, and all comments which are addressed to him directly which shouldn't be visible to him using this vulnerability.
## Attachments
**Warning:** Attachments received through HackerOne, please exercise caution!
* [permissions.png](https://h1.sec.gitlab.net/a/0bac3260-7dcd-4090-bdee-819c95fd4c3e/permissions.png)
* [subscribe.png](https://h1.sec.gitlab.net/a/0dad6348-5cfc-4e97-a52f-35de8f2241dc/subscribe.png)
* [comment.png](https://h1.sec.gitlab.net/a/765b9ae8-0fa3-444f-991f-b96f258796b0/comment.png)
* [todo.png](https://h1.sec.gitlab.net/a/5e0da15c-8582-48b4-83ae-d206ef14cb41/todo.png)12.3Nick ThomasNick Thomas2019-08-23https://gitlab.com/gitlab-org/gitlab-foss/-/issues/64460filter `body` parameter for `/api/:version/projects/:id/issues/:noteable_id/n...2019-08-08T21:45:42ZAntony Sabaasaba@gitlab.comfilter `body` parameter for `/api/:version/projects/:id/issues/:noteable_id/notes` (and probably elsewhere)<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label.
For the Community Edition issue tracker:
- https://gitlab.com/gitlab-org/gitlab-ce/issues?...<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label.
For the Community Edition issue tracker:
- https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=bug
For the Enterprise Edition issue tracker:
- https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
The `body` parameter is currently being logged in the structured rails log. Content that should remain private/confidential is present in logs. This is also an unstructured text field that can be large and causes unnecessary resource usage of logging infrastructure.
### Steps to reproduce
Submit a valid request to the notes route: `/api/:version/projects/:id/issues/:noteable_id/notes`
### What is the current *bug* behavior?
`body` parameter is included in the `params` element.
### What is the expected *correct* behavior?
The `body` parameter should not present or given a placeholder value like `[REMOVED]`.
### Relevant logs and/or screenshots
https://log.gitlab.net/goto/4f5527be8b654331c7dcb0c400037557
### Output of checks
This bug happens on GitLab.com.
### Possible fixes
Add to the filter list will fix the immediate issue, however, this is a repeated, ongoing issue affecting the user privacy of GitLab.com users and projects and should be addressed more systematically by changing to an `allowList` explicitly listing fields to includes in logs: gitlab-org/gitlab-ce#5767312.2Sean McGivernSean McGivern2019-08-23https://gitlab.com/gitlab-org/gitlab-foss/-/issues/64416Update lodash to 4.7.14 and lodash.mergewith to 4.6.22019-07-12T20:21:50ZTakuya NoguchiUpdate lodash to 4.7.14 and lodash.mergewith to 4.6.2#### lodash
https://www.npmjs.com/package/lodash
Affected versions of lodash are vulnerable to Prototype Pollution.
The function defaultsDeep could be tricked into adding or modifying properties of Object.prototype using a constructor ...#### lodash
https://www.npmjs.com/package/lodash
Affected versions of lodash are vulnerable to Prototype Pollution.
The function defaultsDeep could be tricked into adding or modifying properties of Object.prototype using a constructor payload.
Affected versions: < 4.17.13
### lodash.mergewith
https://www.npmjs.com/package/lodash.mergewith
Affected versions of lodash are vulnerable to Prototype Pollution.
The function defaultsDeep could be tricked into adding or modifying properties of Object.prototype using a constructor payload.
Affected versions: < 4.6.212.2Takuya NoguchiTakuya Noguchi2019-08-07https://gitlab.com/gitlab-org/gitlab-foss/-/issues/64033XSS in all areas that accept markdown2022-10-19T15:33:11ZGitLab SecurityBotXSS in all areas that accept markdown**[HackerOne report #633942](https://hackerone.com/reports/633942)** by `samuelmortenson` on 2019-07-02, assigned to `estrike`:
### Summary
Gitlab issue descriptions and other areas that accept markdown like `.md` files in repositories...**[HackerOne report #633942](https://hackerone.com/reports/633942)** by `samuelmortenson` on 2019-07-02, assigned to `estrike`:
### Summary
Gitlab issue descriptions and other areas that accept markdown like `.md` files in repositories are vulnerable to cross site scripting.
### Steps to reproduce
1. Visit any area in Gitlab that accepts markdown (easiest for me is the new issue form)
2. Copy the code from this gist exactly into the markdown textarea: https://gist.github.com/mortenson/55c60006e336c3c4327d62365fcf04d4
3. Click "Preview", or submit the form and load the subsequent page
4. See XSS triggered
I verified that this is exploitable on Gitlab.com, and locally in my instance of Gitlab CE.
### Impact
Any users visiting the page with this payload can have arbitrary JavaScript ran in their user session.
### Examples
I created a private project on Gitlab with an issue that triggers XSS: https://gitlab.com/mortenson/test/issues/1
### What is the current *bug* behavior?
When this specially crafted string is rendered by Gitlab, it results in this output:
```

<img src="o.O" onerror="alert(`samwashere`)">
<iframe></iframe>
```
Which immediately triggers the `onerror` code on page load.
### What is the expected *correct* behavior?
The `onerror` attribute (and any attribute that starts with `on`) should be stripped before HTML is rendered. I wonder if `iframe` tags should be allowed as well.
### Relevant logs and/or screenshots
n/a
### Output of checks
This bug happens on GitLab.com
#### Results of GitLab environment info
For my local Gitlab CE instance:
```
$ docker exec 34dd265dab84 gitlab-rake gitlab:env:info
System information
System:
Current User: git
Using RVM: no
Ruby Version: 2.6.3p62
Gem Version: 2.7.9
Bundler Version:1.17.3
Rake Version: 12.3.2
Redis Version: 3.2.12
Git Version: 2.21.0
Sidekiq Version:5.2.7
Go Version: unknown
GitLab information
Version: 12.0.2
Revision: 1a9fd38a4ca
Directory: /opt/gitlab/embedded/service/gitlab-rails
DB Adapter: PostgreSQL
DB Version: 10.7
URL: http://gitlab.example.com
HTTP Clone URL: http://gitlab.example.com/some-group/some-project.git
SSH Clone URL: git@gitlab.example.com:some-group/some-project.git
Using LDAP: no
Using Omniauth: yes
Omniauth Providers:
GitLab Shell
Version: 9.3.0
Repository storage paths:
- default: /var/opt/gitlab/git-data/repositories
GitLab Shell path: /opt/gitlab/embedded/service/gitlab-shell
Git: /opt/gitlab/embedded/bin/git
```
## Impact
Any that is feasible with XSS - data loss, forwarding of private information, potentially user session hijacking, phishing to get the user to re-enter their password, etc.
Security issue: https://dev.gitlab.org/gitlab/gitlabhq/issues/289612.3Jan Provaznikjprovaznik@gitlab.comJan Provaznikjprovaznik@gitlab.com2019-08-23https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63959Server Side Request Forgery mitigation bypass2022-11-24T18:24:07ZGitLab SecurityBotServer Side Request Forgery mitigation bypass**[HackerOne report #632101](https://hackerone.com/reports/632101)** by `mclaren650sspider` on 2019-06-29, assigned to `dappelt`:
### Summary
This vulnerability allows attacker to send arbitrary requests to local network which hosts Gi...**[HackerOne report #632101](https://hackerone.com/reports/632101)** by `mclaren650sspider` on 2019-06-29, assigned to `dappelt`:
### Summary
This vulnerability allows attacker to send arbitrary requests to local network which hosts GitLab and read the response. This is possible due to flawed DNS rebinding protection.
The attack is possible due to flaw here: https://gitlab.com/gitlab-org/gitlab-ce/blob/108c3cf16bed5733ffae086fb62c226961356560/lib/gitlab/url_blocker.rb#L59
The `validate` function performs DNS lookup to check whether the IP address of a domain belongs to the local network. If the IP address belongs to the local network, the `validate` function raises an error and no HTTP request is sent. Furthermore, `validate` returns URI as well as the IP address of the domain to protect against DNS rebinding attacks.
However, if `validate` encounters an error while resolving the domain (for example, the domain does not resolve), the DNS rebinding protection is not applied.
### Steps to reproduce
1. Create a webhook for a repository on GitLab.com. Use the URL `http://990.hacker1.xyz`. It may return error but let's ignore it now.
2. Wait about 10 seconds and test webhook by clicking on "Test" and "Push events".
3. After the hook has executed, you should see content of `http://169.254.169.254` returned.
Wait about 15 seconds between testing attempts, otherwise it may not work due to DNS caching.
The code for proof-of-concept DNS server which hosts `hacker1.xyz` is attached. The PoC uses a chain of CNAME records to prevent caching.
### What is the current *bug* behavior?
The outgoing HTTP requests from webhooks can be sent to the internal network.
### What is the expected *correct* behavior?
It is expected that HTTP requests cannot be sent to the internal network.
### Relevant logs and/or screenshots
[Screen_Shot_2019-06-29_at_15.36.41.png](https://h1.sec.gitlab.net/a/38b04b5b-0392-478d-8484-0683d3439885/Screen_Shot_2019-06-29_at_15.36.41.png)
Content of `http://169.254.169.254`
[Screen_Shot_2019-06-29_at_15.37.14.png](https://h1.sec.gitlab.net/a/6fe4e583-979a-4f8c-8385-0e1bd899129c/Screen_Shot_2019-06-29_at_15.37.14.png)
Content of `http://127.0.0.1`
### Output of checks
This bug happens on GitLab.com
## Impact
Attacker can use SSRF to access sensitive information on the internal network. Furthermore, SSRF in Google Cloud can be leveraged to Remote Code Execution depending on the setup. Publicly disclosed $25,000 #341876 describes a way to gain root access to Google Cloud server via a SSRF vulnerability.
## Attachments
**Warning:** Attachments received through HackerOne, please exercise caution!
* [Screen_Shot_2019-06-29_at_15.37.14.png](https://h1.sec.gitlab.net/a/6fe4e583-979a-4f8c-8385-0e1bd899129c/Screen_Shot_2019-06-29_at_15.37.14.png)
* [Screen_Shot_2019-06-29_at_15.36.41.png](https://h1.sec.gitlab.net/a/38b04b5b-0392-478d-8484-0683d3439885/Screen_Shot_2019-06-29_at_15.36.41.png)
* [Gitlab_DNS_PoC.tar](https://h1.sec.gitlab.net/a/fb1f4cc0-a20c-4be4-93f3-3838ab9e18c9/Gitlab_DNS_PoC.tar)12.1Francisco Javier López (ex-Gitlab)Francisco Javier López (ex-Gitlab)https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63945Update mixin-deep to 1.3.22019-09-25T03:57:52ZTakuya NoguchiUpdate mixin-deep to 1.3.2Update mixin-deep from 1.3.1 to 1.3.2 to address a Prototype Pollution vulnerability, which exists in `mixin-deep` package, versions `>=2.0.0 <2.0.1 || <1.3.2` (CVE-2019-10746).
- from: https://www.npmjs.com/package/mixin-deep/v/1.3.1
-...Update mixin-deep from 1.3.1 to 1.3.2 to address a Prototype Pollution vulnerability, which exists in `mixin-deep` package, versions `>=2.0.0 <2.0.1 || <1.3.2` (CVE-2019-10746).
- from: https://www.npmjs.com/package/mixin-deep/v/1.3.1
- to: https://www.npmjs.com/package/mixin-deep/v/1.3.2
- 2 commits (github.com): https://github.com/jonschlinkert/mixin-deep/compare/1.3.1...1.3.2
- Synk ID: https://app.snyk.io/vuln/SNYK-JS-MIXINDEEP-45021212.1Takuya NoguchiTakuya Noguchi2019-07-07https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63534Security impact of setimmediate.js2024-02-07T17:35:12ZEthan StrikeSecurity impact of setimmediate.js<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label.
For the Community Edition issue tracker:
- https://gitlab.com/gitlab-org/gitlab-ce/issues?...<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label.
For the Community Edition issue tracker:
- https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=bug
For the Enterprise Edition issue tracker:
- https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
A customer reported that the `main.<hash>.chunk.js` file used in GitLab was being flagged by a security scanner for including the code `window.postMessage(message, "*")`. In this example, the origin is not being validated through the use of "*", which could be a security concern. It was determined that the code was added to `main.<hash>.chunk.js` by the [setimmediate.js](https://github.com/YuzuJS/setImmediate) library, which uses `postMessage` to add tasks to the global event queue to allow for asynchronous execution.
This issue is to determine the following:
- [ ] Confirm dependencies which introduce `setimmediate` as a dependency
- [ ] The security impact of using the library, if any
- [ ] Define a solution if a security impact is determined.
Zendesk ticket (internal access only): https://gitlab.zendesk.com/agent/tickets/124038
### Steps to reproduce
Download the latest `main.<hash>.chunk.js` from gitlab.com
### What is the current *bug* behavior?
The following code is included, which passes a message to the global context.
```javascript
function installPostMessageImplementation() {
// Installs an event handler on `global` for the `message` event: see
// * https://developer.mozilla.org/en/DOM/window.postMessage
// * http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#crossDocumentMessages
var messagePrefix = "setImmediate$" + Math.random() + "$";
var onGlobalMessage = function(event) {
if (event.source === global &&
typeof event.data === "string" &&
event.data.indexOf(messagePrefix) === 0) {
runIfPresent(+event.data.slice(messagePrefix.length));
}
};
if (global.addEventListener) {
global.addEventListener("message", onGlobalMessage, false);
} else {
global.attachEvent("onmessage", onGlobalMessage);
}
registerImmediate = function(handle) {
global.postMessage(messagePrefix + handle, "*");
};
}
```
### What is the expected *correct* behavior?
Determine if and how code can be removed. This will reduce customer impact if found in other scans.
#### Results of GitLab environment info
Reproducible on `gitlab.com`
### Possible fixes
Remove `setimmediate` as a dependency in production.
`gitlab/node_modules/setimmediate/`
Dependency tree
```
`-- eslint-import-resolver-webpack@0.10.1
`-- node-libs-browser@2.1.0
`-- timers-browserify@2.0.10
`-- setimmediate@1.0.5
```
`node-libs-browser` is also a dependency of `webpack`, which is a production dependency
```
`-- webpack@4.29.0
`-- node-libs-browser@2.1.0
```
Webpack: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/package.json#L1402019-09-19https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63502Store deploy tokens encrypted2021-05-27T09:35:25ZKrasimir AngelovStore deploy tokens encryptedSimilar to https://gitlab.com/gitlab-org/gitlab-ce/issues/57918 we are currently storing deploy tokens in plain text in the DB. We should change to create new tokens encrypted and also encrypt existing ones.Similar to https://gitlab.com/gitlab-org/gitlab-ce/issues/57918 we are currently storing deploy tokens in plain text in the DB. We should change to create new tokens encrypted and also encrypt existing ones.12.3Etienne BaquéEtienne Baqué2019-09-30https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63403Restricted repo trees can be scanned via GraphQL2019-08-02T14:29:06ZGitLab SecurityBotRestricted repo trees can be scanned via GraphQL**[HackerOne report #614453](https://hackerone.com/reports/614453)** by `xanbanx` on 2019-06-14, assigned to `jmatos_bgtvf`:
### Summary
GitLab added a new GraphQL API to query the repo tree. However, this API does not respect the user...**[HackerOne report #614453](https://hackerone.com/reports/614453)** by `xanbanx` on 2019-06-14, assigned to `jmatos_bgtvf`:
### Summary
GitLab added a new GraphQL API to query the repo tree. However, this API does not respect the user permissions. For repos with restricted access, any user who has access to the project, but not to the repo, can query the repo tree via the GraphQL API.
This happens for:
* Public projects with repositories set to `Project Members` only
* Internal projects with repositories set to `Project Members` only
* Private projects where guest users do not have access to the repository
### Steps to reproduce
(Step-by-step guide to reproduce the issue, including:)
1. Create a public repo, with the repository restricted to project members only and push some code
2. As an unauthenticated user, perform the following graphql request. You can do that for example using the GitLab inbuilt GraphQL explorer.
```json
{
project(fullPath: "<namespace>/<project-name>") {
id
repository {
empty
exists
rootRef
tree {
blobs {
edges {
node {
id
flatPath
path
type
webUrl
}
}
}
}
}
}
}
```
3. Although you are unauthenticated and the repo access is restricted to project members only, you receive the repository tree like for example
```json
{
"data": {
"project": {
"id": "gid://gitlab/Project/1",
"repository": {
"empty": false,
"exists": true,
"rootRef": "master",
"tree": {
"blobs": {
"edges": [
{
"node": {
"id": "f754ff5ab666e7bce419a8184ec9ba54c15852b2",
"flatPath": "Readme.md",
"path": "Readme.md",
"type": "blob",
"webUrl": "https://example.gitlab.net/test/test-repo/blob/88340bca02ab25c8356258f9540d281295cdda8/README.md"
}
},
{
"node": {
"id": "536aca34dbae6b2bca83bebdcba83543c9546f0",
"flatPath": "secret",
"path": "secret",
"type": "blob",
"webUrl": "https://example.gitlab.net/test/test-repo/blob/88340bca02ab25c8356258f9540d281295cdda8/secret"
}
}
]
}
}
}
}
}
}
```
### Examples
This happens on GitLab.com tested on 12.0.0-pre d56096df9a5. You can use the repo `wter23/repo-restricted` on gitlab.com to reproduce that behavior. This public project has the repo restricted to project members only and therefore does not show up in the user interface. However, GraphQL allows you to crawl the repository tree .
### What is the current *bug* behavior?
Unauthorized users have access to the project tree.
### What is the expected *correct* behavior?
Unauthorized users should not access to the project tree.
## Impact
Unauthorized users, who do not have access to the repo can crawl the project tree and therefore have access to private information. I consider the repo as the heart of a GitLab project and therefore consider this as a "high" report.12.0Bob Van Landuytbob@gitlab.comBob Van Landuytbob@gitlab.com2019-07-24https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63389Timeline activities discloses merge request ID associated with an issue to gu...2020-12-07T16:50:22ZGitLab SecurityBotTimeline activities discloses merge request ID associated with an issue to guests**[HackerOne report #588876](https://hackerone.com/reports/588876)** by `ashish_r_padelkar` on 2019-05-23, assigned to `jmatos_bgtvf`:
### Summary
Hello,
In private projects, `Guests` users are not allowed to see any information relat...**[HackerOne report #588876](https://hackerone.com/reports/588876)** by `ashish_r_padelkar` on 2019-05-23, assigned to `jmatos_bgtvf`:
### Summary
Hello,
In private projects, `Guests` users are not allowed to see any information related to merge requests. However, It is possible for them to see the merge request ID associated with an issue( If any) through timeline activity!
### Steps to reproduce
1. As an owner of private project, create a merge request for an issue using below button.
![Screenshot_2019-05-24_at_00.38.14.png](https://h1.sec.gitlab.net/a/1d4282d0-e309-45bc-9e14-493db1e3ca4c/Screenshot_2019-05-24_at_00.38.14.png)
2. When merge request is created, the timeline activity is also created which is then visible to Guest users in project.
![Screenshot_2019-05-24_at_00.35.07.png](https://h1.sec.gitlab.net/a/b80e3605-7162-4cb4-be95-1f8f91b2c343/Screenshot_2019-05-24_at_00.35.07.png)
### What is the current *bug* behavior?
Timeline activity discloses the merge request ID of an issue
### What is the expected *correct* behavior?
No information related to merge request should be visible to guest users
### Output of checks
This bug happens on GitLab.com and also on omnibus installations too!
Regards,
Ashish
## Impact
Guests users can see merge request ID associated with an issue in private projects!
## Attachments
**Warning:** Attachments received through HackerOne, please exercise caution!
* [Screenshot_2019-05-24_at_00.38.14.png](https://h1.sec.gitlab.net/a/1d4282d0-e309-45bc-9e14-493db1e3ca4c/Screenshot_2019-05-24_at_00.38.14.png)
* [Screenshot_2019-05-24_at_00.35.07.png](https://h1.sec.gitlab.net/a/b80e3605-7162-4cb4-be95-1f8f91b2c343/Screenshot_2019-05-24_at_00.35.07.png)12.3Igor Drozdovidrozdov@gitlab.comIgor Drozdovidrozdov@gitlab.com2019-08-23https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63386GraphQL query "namespace" leaks data2019-08-02T14:32:21ZGitLab SecurityBotGraphQL query "namespace" leaks data**[HackerOne report #614355](https://hackerone.com/reports/614355)** by `rpadovani` on 2019-06-14, assigned to `jmatos_bgtvf`:
> NOTE! Thanks for submitting a report! Please replace *all* the (parenthesized) sections below with the pert...**[HackerOne report #614355](https://hackerone.com/reports/614355)** by `rpadovani` on 2019-06-14, assigned to `jmatos_bgtvf`:
> NOTE! Thanks for submitting a report! Please replace *all* the (parenthesized) sections below with the pertinent details. Remember, the more detail you provide, the easier it is for us to triage and respond quickly, so be sure to take your time filling out the report!
### Summary
Using the "namespace" query on Graphql you can retrieve some private data that is not available through Standard API or through Web API
### Steps to reproduce
#### User namespace
1. My Gitlab profile is private: https://gitlab.com/rpadovani
2. You cannot access a list of my projects: https://gitlab.com/users/rpadovani/contributed
3. You cannot access these data through the standard APIs:
```
curl --header "PRIVATE-TOKEN: anotherUserToken" 'https://gitlab.com/api/v4/namespaces/16048'
{"message":"404 Namespace Not Found"}
```
(rpadovani user id is 16048, I used access token of another user for this curl request)
4. You can however access all these data, without any token (so no need to be registered), through Graphql:
```
curl 'https://gitlab.com/api/graphql' -H 'Content-Type: application/json' --data '{"query":"{namespace(fullPath:\"rpadovani\") {description\n requestAccessEnabled\n fullName\n fullPath\n id\n lfsEnabled\n name\n path\n visibility\n projects (includeSubgroups: true, ) {edges {node {id\n name\n archived\n visibility\n description}}}}}","variables":null,"operationName":null}'
```
Response (omitted other 19 projects for brevity):
```
{"data":{"namespace":{"description":"","requestAccessEnabled":true,"fullName":"rpadovani","fullPath":"rpadovani","id":"gid://gitlab/Namespace/18021","lfsEnabled":true,"name":"rpadovani","path":"rpadovani","visibility":"public","projects":{"edges":[{"node":{"id":"gid://gitlab/Project/11265641","name":"737-max-8","archived":false,"visibility":"public","description":"https://737max8.com"}}, ...OMIT...
```
#### Group namespace
A Graphql query on a secret group / subgroup can bring to disclose the description of the group
1. No access from GUI: https://gitlab.com/secret-group-213
2. Access through GraphQL (please notice I do not provide any access token, at all):
```
curl 'https://gitlab.com/api/graphql' -H 'Content-Type: application/json' --data '{"query":"{namespace(fullPath:\"secret-group-213\") {description\n requestAccessEnabled\n fullName\n fullPath\n id\n lfsEnabled\n name\n path\n visibility\n projects (includeSubgroups: true, ) {edges {node {id\n name\n archived\n visibility\n description}}}}}","variables":null,"operationName":null}'
```
Response:
```
{"data":{"namespace":{"description":"This description is secret!","requestAccessEnabled":false,"fullName":"secret group","fullPath":"secret-group-213","id":"gid://gitlab/Group/5337756","lfsEnabled":true,"name":"secret group","path":"secret-group-213","visibility":"private","projects":{"edges":[]}}}}
```
### Impact
This Graphql query makes the `private profile` feature quite useless, and leaks the description and some other information about private groups and subgroups.
The impact is limited because the GraphQL implementation is still at the beginning, I think that the impact of this issue would be bigger, if the GraphQL implementation was au-pair with the APIs implementation
### Examples
(If the bug is project related, please create an example project and export it using the project export feature)
(If you are using an older version of GitLab, this will also help determine whether the bug has been fixed in a more recent version)
(If the bug can be reproduced on GitLab.com without violating the `Rules of Engagement` as outlined in the program policy, please provide the full path to the project.)
### What is the current *bug* behavior?
Access data that shouldn't be accessed
### What is the expected *correct* behavior?
empty response
### Output of checks
This bug happens on GitLab.com
#### Results of GitLab environment info
## Impact
An attacker can bypass the "private profile" check, and can access metadata about secret groups12.0Bob Van Landuytbob@gitlab.comBob Van Landuytbob@gitlab.com2019-07-24https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63345Project member with Reporter permission able to read wiki history via "git cl...2020-12-10T18:55:54ZGitLab SecurityBotProject member with Reporter permission able to read wiki history via "git clone ...; git log"**[HackerOne report #604611](https://hackerone.com/reports/604611)** by `nikitastupin` on 2019-06-09, assigned to `jmatos_bgtvf`:
### Summary
Hi,
Project member with Guest or Reporter permission can't view project wiki history using w...**[HackerOne report #604611](https://hackerone.com/reports/604611)** by `nikitastupin` on 2019-06-09, assigned to `jmatos_bgtvf`:
### Summary
Hi,
Project member with Guest or Reporter permission can't view project wiki history using web interface. However Reporter can view wiki history by first cloning repository via `git clone https://gitlab.com/:username/:project.wiki.git` and then locally running `git log`.
If project is public wiki can be cloned even with anonymous access.
### Steps to reproduce
1. Create a private project. Create a wiki page. Add member with Reporter permissions to the project.
2. Go to terminal and execute `git clone https://gitlab.com/:username/:project.wiki.git` where `:username` is the name of project owner and `:project` is the project name. Enter Reporter's username and password when git ask it.
3. Run `git log` inside the repository.
### Impact
Unauthorised members can see wiki history.
### Examples
Project export: REDACTED.
Full path to the project: https://gitlab.com/nshackerone/aclmon-private-project.
### What is the current *bug* behavior?
```
$ git clone https://gitlab.com/nshackerone/aclmon-private-project.wiki.git
Cloning into 'aclmon-private-project.wiki'...
Username for 'https://gitlab.com': ns3hackerone
Password for 'https://ns3hackerone@gitlab.com':
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
```
### What is the expected *correct* behavior?
```
$ git clone https://gitlab.com/nshackerone/aclmon-private-project.wiki.git
Cloning into 'aclmon-private-project.wiki'...
Username for 'https://gitlab.com': ns3hackerone
Password for 'https://ns3hackerone@gitlab.com':
remote: You are not allowed to download code from this project.
fatal: unable to access 'https://gitlab.com/nshackerone/aclmon-private-project.wiki.git/': The requested URL returned error: 403
```
### Output of checks
This bug happens on GitLab.com
## Impact
Unauthorised members can see wiki history.
## Attachments
**Warning:** Attachments received through HackerOne, please exercise caution!
* REDACTED12.2Alex KalderimisAlex Kalderimis2019-08-23https://gitlab.com/gitlab-org/gitlab-foss/-/issues/63124Disclosure of Merge Request ID to Unauthorized Users2019-10-01T09:22:18ZEthan StrikeDisclosure of Merge Request ID to Unauthorized Users<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label.
For the Community Edition issue tracker:
- https://gitlab.com/gitlab-org/gitlab-ce/issues?...<!---
Please read this!
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "regression" or "bug" label.
For the Community Edition issue tracker:
- https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=bug
For the Enterprise Edition issue tracker:
- https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=regression
- https://gitlab.com/gitlab-org/gitlab-ee/issues?label_name%5B%5D=bug
and verify the issue you're about to submit isn't a duplicate.
--->
### Summary
When an issue is closed via a merge request, the email notification to users which have access to issues, but not the repository, will include a reference to the merge request. This includes users, which are:
- Guests in private projects
- Non-project users in public/internal project where access to the repository has been limited to `Project Members Only`.
### Steps to reproduce
1. Create private project with user2 as a Guest
2. Create an issue
3. Tag user2 in issue so that they receive notifications
4. Create a merge request, which closes the issue
5. Merge the merge request to close the issue
### What is the current *bug* behavior?
User2 above will receive an email with the following text
`Issue was closed by User1 via merge request!1`
### What is the expected *correct* behavior?
The merge request reference should not be included in the email.
### Output of checks
This happens on GitLab.com
### Possible fixes
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/helpers/emails_helper.rb#L91 does not validate the user has permission to reference the Merge Request before including the reference in email body.12.3Felipe ArturFelipe Artur2019-09-23