T09 · Insecure Skill Coding Practices
- Location
gitlab-client.js:113- Finding
GitLab Access Token Disclosure Through Unsafe Redirects and Plaintext HTTP
- Content
View full analysis
{ // Handle redirects if ([301, 302, 307, 308].includes(res.statusCode) && res.headers.location) { if (redirectsLeft <= 0) return reject(new Error('Too many redirects')); const next = new URL(res.headers.location, urlStr).toString(); return doRequest(next, redirectsLeft - 1); } ``` ### Technical Analysis The request helper accepts both HTTP and HTTPS destinations and attaches the `PRIVATE-TOKEN` authentication header to every request. It also follows up to five redirects without checking whether the redirect changes the protocol, hostname, or port. Consequently, a redirect from the configured GitLab server to an attacker-controlled origin causes the client to forward the same GitLab personal access token to that origin. A redirect can also downgrade an HTTPS request to HTTP, exposing the token to passive or active network interception. The same plaintext disclosure risk exists when `GITLAB_URL` is configured directly with an `http:` URL. There is no transport validation in `getConfig()` or `request()` to reject such a configuration. ### Attack Path 1. A user configures `GITLAB_URL` and a valid `GITLAB_TOKEN`. 2. The user invokes any supported GitLab command. 3. ...[truncated 1490 chars]- Remediation
View remediation
