Skip to content
Snippets Groups Projects
Select Git revision
  • move-gl-dropdown
  • improve-table-pagination-spec
  • move-markdown-preview
  • winh-fix-merge-request-spec
  • master default
  • index-namespaces-lower-name
  • winh-single-karma-test
  • 10-3-stable
  • 36782-replace-team-user-role-with-add_role-user-in-specs
  • winh-modal-internal-state
  • tz-ide-file-icons
  • 38869-milestone-select
  • update-autodevops-template
  • jivl-activate-repo-cookie-preferences
  • qa-add-deploy-key
  • docs-move-article-ldap
  • 40780-choose-file
  • 22643-manual-job-page
  • refactor-cluster-show-page-conservative
  • dm-sidekiq-versioning
  • v10.4.0.pre
  • v10.3.0
  • v10.3.0-rc5
  • v10.3.0-rc4
  • v10.3.0-rc3
  • v10.3.0-rc2
  • v10.2.5
  • v10.3.0-rc1
  • v10.0.7
  • v10.1.5
  • v10.2.4
  • v10.2.3
  • v10.2.2
  • v10.2.1
  • v10.3.0.pre
  • v10.2.0
  • v10.2.0-rc4
  • v10.2.0-rc3
  • v10.1.4
  • v10.2.0-rc2
40 results

groups.html.haml

Forked from GitLab.org / GitLab FOSS
9845 commits behind the upstream repository.
  • Rémy Coutable's avatar
    aec3475d
    Fix an information disclosure when requesting access to a group containing private projects · aec3475d
    Rémy Coutable authored
    
    The issue was with the `User#groups` and `User#projects` associations
    which goes through the `User#group_members` and `User#project_members`.
    
    Initially I chose to use a secure approach by storing the requester's
    user ID in `Member#created_by_id` instead of `Member#user_id` because I
    was aware that there was a security risk since I didn't know the
    codebase well enough.
    
    Then during the review, we decided to change that and directly store the
    requester's user ID into `Member#user_id` (for the sake of simplifying
    the code I believe), meaning that every `group_members` / `project_members`
    association would include the requesters by default...
    
    My bad for not checking that all the `group_members` / `project_members`
    associations and the ones that go through them (e.g. `Group#users` and
    `Project#users`) were made safe with the `where(requested_at: nil)` /
    `where(members: { requested_at: nil })` scopes.
    
    Now they are all secure.
    
    Signed-off-by: default avatarRémy Coutable <remy@rymai.me>
    Verified
    aec3475d
    History
    Fix an information disclosure when requesting access to a group containing private projects
    Rémy Coutable authored
    
    The issue was with the `User#groups` and `User#projects` associations
    which goes through the `User#group_members` and `User#project_members`.
    
    Initially I chose to use a secure approach by storing the requester's
    user ID in `Member#created_by_id` instead of `Member#user_id` because I
    was aware that there was a security risk since I didn't know the
    codebase well enough.
    
    Then during the review, we decided to change that and directly store the
    requester's user ID into `Member#user_id` (for the sake of simplifying
    the code I believe), meaning that every `group_members` / `project_members`
    association would include the requesters by default...
    
    My bad for not checking that all the `group_members` / `project_members`
    associations and the ones that go through them (e.g. `Group#users` and
    `Project#users`) were made safe with the `where(requested_at: nil)` /
    `where(members: { requested_at: nil })` scopes.
    
    Now they are all secure.
    
    Signed-off-by: default avatarRémy Coutable <remy@rymai.me>
groups.html.haml 896 B