Skip to content

1-click account takeover via XSS in the code editor in gitlab.com

⚠ Please read the process on how to fix security issues before starting to work on the issue. Vulnerabilities must be fixed in a security mirror.

HackerOne report #2497024 by matanber on 2024-05-09, assigned to @ottilia_westerlund:

Report | How To Reproduce

Report

Summary

Like in every web-based VS Code instance, the web page for the GitLab Web IDE includes a "webWorkerExtensionHostIframe.html" file (hosted at https://gitlab.com/assets/webpack/gitlab-vscode/0.0.1-dev-20240501001436/vscode/out/vs/workbench/services/extensions/worker/webWorkerExtensionHostIframe.html) in an iframe. This iframe is responsible for running VS Code extensions, and it communicates with its parent window via postMessages. However, the postMessage listener in this iframe does not properly validate the origin of the messages which it receives. This allows a malicious site to include the webWorkerExtensionHostIframe.html file in an iframe and interact with it as if it was the web page for the web IDE. This site can then instruct the extension host to load an arbitrary JS file as an extension, leading to arbitrary JS code execution in the https://gitlab.com origin.

In order to exploit this issue, I logged all of the messages which are normally sent to the extension host by the page, and then modified the content of one of the messages which includes an object representing the URL of the JS file of the gitlab-ide extension, and modified the object so that it represents the URL of a malicious JS file (https://peo.si/gl/editor/include.js). Then, I created a PoC page hxxps://peo.si/gl/editor/poc-frame.html which simply sends all of the messages in the log file in sequence.

Steps to reproduce
  1. As the victim, log in to your account in gitlab.com.
  2. Navigate to hxxps://peo.si/gl/editor/poc-frame.html
  3. Notice the API token which was logged in the console.
  4. Navigate to https://gitlab.com/-/user_settings/personal_access_tokens, and notice the malicious API token which was added to your account.
What is the current bug behavior?

The webWorkerExtensionHostIframe.html file is hosted in the https://gitlab.com origin.

What is the expected correct behavior?

The webWorkerExtensionHostIframe.html file should be hosted in a unique sandbox origin. This is the behavior which exists in the vscode.dev and github.dev web-based VS Code instances.

Output of checks

This bug happens on GitLab.com

Impact

An attacker can take over a victim's GitLab account, with a single click from the victim.

How To Reproduce

Please add reproducibility information to this section:

Edited by Ottilia Westerlund