Stored XSS in Wiki pages

### Summary I found Stored XSS using Wiki-specific Hierarchical link Markdown in Wiki pages. ### Steps to reproduce 1. Sign in to GitLab. 2. Open a Project page that you have permission to edit Wiki pages. 3. Open Wiki page. 4. Click "New page" button. 5. Fill out "Page slug" form with `blocked:`. 6. Click "Create page" button. 7. Fill out the each form as follows: Title: `blocked:` Format: Markdown Content: `[XSS](.alert(1);)` (Please see "CreatePage.png") {F462086} 8. Click "Create page" button. 9. Click "XSS" link in created page. ### What is the current *bug* behavior? The alert dialog appears after clicking "XSS" link in created page. Please see "Result_Firefox.png". {F462087} #### Description In Detail: GitLab application converts the Markdown string `.alert(1);` to the href attribute `blocked:alert(1);`. Furthermore, Wiki-specific Markdown string `.` is converted to `blocked:` in this case. ### What is the expected *correct* behavior? The dangerous href attribute `blocked:alert(1);` should be filtered. A safe HTTP/HTTPS link should be rendered instead. ### Additional Informations: 1. In the above case, another Wiki-specific Markdown string `..` is also converted to `blocked:`. 2. Using Title string such as `blocked:STRING_EXPECTED_REMOVING` also reproduces this vulnerability. For example, if a wiki page is created with a disguised Title string `blocked::SubClassName.function_name`, GitLab application converts Wiki-specific Markdown string `.` to `blocked:` in such page. It seems that GitLab application recognizes scheme-like string `blocked:` and removes the rest of Title string `:SubClassName.function_name`. 3. An attacker can use various schemes by replacing Title string `blocked:` to other scheme. (e.g. `blocked:`, `vbscript:`, and so on.) ### Output of checks This bug happens on the official Docker installation of GitLab Enterprise Edition 11.9.4-ee. #### Results of GitLab environment info Output of `sudo gitlab-rake gitlab:env:info`: ``` System information System: Proxy: no Current User: git Using RVM: no Ruby Version: 2.5.3p105 Gem Version: 2.7.6 Bundler Version:1.16.6 Rake Version: 12.3.2 Redis Version: 3.2.12 Git Version: 2.18.1 Sidekiq Version:5.2.5 Go Version: unknown GitLab information Version: 11.9.4-ee Revision: 55be7f0 Directory: /opt/gitlab/embedded/service/gitlab-rails DB Adapter: postgresql DB Version: 9.6.11 URL: http://gitlab.example.com HTTP Clone URL: http://gitlab.example.com/some-group/some-project.git SSH Clone URL: [email protected]:some-group/some-project.git Elasticsearch: no Geo: no Using LDAP: no Using Omniauth: yes Omniauth Providers: GitLab Shell Version: 8.7.1 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 If wiki pages created by using this vulnerability are visible to everyone (Wiki Visibility setting is set to "Everyone With Access") in "Public" project, there is a possibility that a considerable number of GitLab users and visitors click a malicious link.