Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 54.9k
    • Issues 54.9k
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1.5k
    • Merge requests 1.5k
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Terraform modules
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #377970
Closed
Open
Issue created Oct 14, 2022 by GitLab SecurityBot@gitlab-securitybotReporter

Cross-site scripting in "Maximum page reached" page affecting self-hosted instances running without strict CSP

HackerOne report #1728015 by ryotak on 2022-10-10, assigned to @cmaxim:

Report | Attachments | How To Reproduce

Report

Summary

Due to the use of non-filtered params in the Maximum page reached page, an attacker can execute arbitrary JavaScript on the self-hosted instances running without strict CSP.

Description

In app/views/explore/projects/page_out_of_bounds.html.haml, the following code is used to generate a link to return to the explore page.

app/views/explore/projects/page_out_of_bounds.html.haml line 21

      = link_to _("Back to page %{number}") % { number: [@]max_page_number }, request.params.merge(page: [@]max_page_number), class: 'gl-button btn btn-inverted'  

As request.params instead of safe_params is used to pass parameters to link_to, arbitrary parameters can be passed here.
Since link_to supports parameters such as protocol or host, it's possible to inject javascript: URLs and achieves XSS.

Steps to reproduce
Self-hosted instance (with an alert)
  1. Set up your own GitLab instance.
  2. Open https://YOUR_OWN_INSTANCE/explore/projects?page=51&protocol=javascript&host=%250dalert(document.domain)//
  3. Click Back to page 50
  4. Confirm that alert(document.domain) has been executed.
GitLab.com (with a CSP error message)
  1. Open https://gitlab.com/explore/projects?page=51&protocol=javascript&host=%250dalert(document.domain)//
  2. Open DevTools.
  3. Click Back to page 50.
  4. Confirm that CSP prevented the execution of JavaScript.
Examples

https://gitlab.com/explore/projects?page=51&protocol=javascript&host=%250dalert(document.domain)//

What is the current bug behavior?

request.params is used, which may include dangerous parameters.

What is the expected correct behavior?

safe_params should be used to filter the dangerous parameters.

Relevant logs and/or screenshots

2022-10-10_14-45-24.mp4

Results of GitLab environment info
System information  
System:         Ubuntu 20.04  
Proxy:          no  
Current User:   git  
Using RVM:      no  
Ruby Version:   2.7.5p203  
Gem Version:    3.1.6  
Bundler Version:2.3.15  
Rake Version:   13.0.6  
Redis Version:  6.2.7  
Sidekiq Version:6.4.2  
Go Version:     unknown

GitLab information  
Version:        15.4.1-ee  
Revision:       7b2ed8f038f  
Directory:      /opt/gitlab/embedded/service/gitlab-rails  
DB Adapter:     PostgreSQL  
DB Version:     13.6  
URL:            https://gl.ryotak.me  
HTTP Clone URL: https://gl.ryotak.me/some-group/some-project.git  
SSH Clone URL:  git@gl.ryotak.me:some-group/some-project.git  
Elasticsearch:  no  
Geo:            no  
Using LDAP:     no  
Using Omniauth: yes  
Omniauth Providers:

GitLab Shell  
Version:        14.10.0  
Repository storage paths:  
- default:      /var/opt/gitlab/git-data/repositories  
GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell  

Impact

An attacker can execute arbitrary JavaScript on the victim's browser and do any actions on behalf of the user.

Attachments

Warning: Attachments received through HackerOne, please exercise caution!

  • 2022-10-10_14-45-24.mp4

How To Reproduce

Please add reproducibility information to this section:

Assignee
Assign to
Time tracking