GitLab CVE-2023-7028漏洞复现：密码重置逻辑缺陷与账户接管实战

1. 项目概述与漏洞背景

最近在安全圈里，GitLab的CVE-2023-7028漏洞讨论得挺热。这个漏洞的官方描述是“通过电子邮件重置密码时存在账户接管风险”，听起来有点抽象，但说白了，它能让攻击者在某些情况下，绕过密码重置流程，直接接管你的GitLab账户。我花了点时间，在自己的测试环境里把这个漏洞的触发条件和利用过程完整走了一遍，过程中用Burp Suite抓了包，把关键的数据流都截图记录了下来。这篇文章，我就来手把手带你把这个漏洞的复现过程捋清楚，从环境搭建到漏洞触发，再到Burp Suite的实战抓包分析，让你不仅能看懂，还能自己动手试。

这个漏洞影响的范围其实不小，根据官方公告，它影响了GitLab CE/EE的多个版本。对于企业内部的代码仓库或者使用GitLab进行项目管理的团队来说，如果这个漏洞被利用，攻击者就能以你的身份登录，看到所有代码、提交记录，甚至进行恶意提交或删除操作，后果可想而知。所以，无论是作为安全研究人员学习漏洞原理，还是作为运维人员自查自纠，理解这个漏洞都很有必要。接下来，我会假设你有一个基础的测试环境（比如用Docker快速拉起一个存在漏洞的GitLab版本），并且对Burp Suite这类工具有基本的了解。我们会一步步拆解，看看这个漏洞到底是怎么发生的。

2. 漏洞原理深度解析：密码重置流程的“信任”裂痕

要理解CVE-2023-7028，我们得先看看GitLab正常的密码重置流程是怎么设计的。当你点击“忘记密码”时，通常的流程是：输入注册邮箱 -> 系统向该邮箱发送一封包含重置令牌的链接 -> 用户点击链接进入重置页面 -> 设置新密码。这个流程的核心是“信任”：系统信任你拥有对那个邮箱的接收权。而CVE-2023-7028的根源，就出在GitLab处理密码重置请求时，对用户提交的“身份标识”参数的处理逻辑上。

在漏洞版本中，GitLab的密码重置接口（通常是/users/password这个POST请求）在接收参数时，存在一个参数解析的问题。攻击者可以构造一个特殊的请求，在其中注入额外的参数，从而尝试让系统将重置链接发送到攻击者控制的邮箱，而不是账户原本绑定的邮箱。这听起来有点像“参数污染”或“参数注入”，但它的本质是后端代码在拼接、验证多个用户标识字段（比如email字段，或者在某些API中可能存在的user[email]等复合参数）时，没有进行严格的、唯一的有效性校验和绑定。

更具体地说，后端可能接收了一个包含多个邮箱地址的数组，或者通过某种方式解析了恶意构造的字符串，导致在生成重置令牌并发送邮件时，错误地选取了攻击者提供的邮箱地址作为目标。而安全的设计应该是：首先，严格验证提交的标识（如邮箱）是否确实与某个用户账户绑定；其次，整个重置令牌必须且只能发送到该账户经过验证的、唯一的联系邮箱。漏洞版本的逻辑在这里出现了偏差，使得“信任链”断裂了。

注意：在实际测试中，触发这个漏洞可能需要满足特定条件，比如GitLab的配置（是否允许通过API进行密码重置）、用户账户的状态等。并不是所有情况都能成功，这也是为什么我们需要搭建一个精准的测试环境来复现。

3. 复现环境搭建与前期准备

复现漏洞，第一步就是搭建一个“靶场”。最方便的方法就是使用Docker。我们需要拉取一个存在CVE-2023-7028漏洞的特定GitLab版本。根据漏洞公告，受影响的版本范围是有限的，你需要选择一个明确存在漏洞的版本，例如某个具体的15.x或16.x的早期版本。这里以gitlab/gitlab-ce:15.5.0-ce.0为例（请注意，实际版本号需根据漏洞详情精确选择，此处仅为演示）。

# 拉取特定版本的GitLab CE镜像 docker pull gitlab/gitlab-ce:15.5.0-ce.0 # 运行GitLab容器 docker run --detach \ --hostname gitlab.example.com \ --publish 443:443 --publish 80:80 --publish 22:22 \ --name gitlab-test \ --restart always \ --volume /srv/gitlab/config:/etc/gitlab \ --volume /srv/gitlab/logs:/var/log/gitlab \ --volume /srv/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:15.5.0-ce.0

启动后需要等待几分钟，直到服务完全初始化。你可以通过docker logs -f gitlab-test查看日志，当看到“GitLab is ready!”之类的提示时，就可以通过宿主机的IP（如http://your-server-ip）访问GitLab的Web界面了。

接下来是配置Burp Suite。你需要将浏览器的代理设置为Burp Suite（默认127.0.0.1:8080），并在Burp中安装你的浏览器证书，以确保能拦截和查看HTTPS流量。这一步是后续抓包分析的基础，务必确保Burp Suite能正常捕获到你对GitLab站点的所有HTTP/HTTPS请求。同时，在GitLab上，你需要至少创建两个测试账户：一个“受害者”账户（比如victim@test.com），一个“攻击者”账户（比如attacker@test.com）。当然，攻击者账户的邮箱需要是你实际能接收邮件的，用于验证是否能接收到本应发给受害者的重置邮件。

4. 利用Burp Suite进行漏洞探测与请求构造

环境就绪后，我们开始实战。首先，用“受害者”账户登录，然后退出。接着，在登录页面点击“Forgot your password?”，你会进入密码重置页面。正常情况下，你只需要输入victim@test.com并提交。但我们的目的是拦截并修改这个请求。

打开Burp Suite的Proxy -> Intercept，确保拦截是开启的。然后在GitLab的密码重置页面输入victim@test.com，点击“Reset password”。此时，请求会被Burp Suite截获。你会看到一个POST请求发送到/users/password路径。关键的突破口就在这个请求的Body里。

最初的请求Body可能看起来像这样（Content-Type: application/x-www-form-urlencoded）：

authenticity_token=XXXX&user%5Bemail%5D=victim%40test.com

这里user%5Bemail%5D就是user[email]的URL编码形式。现在，我们需要尝试构造恶意参数。根据漏洞原理，我们需要尝试以某种方式注入第二个邮箱地址。一种常见的测试方法是参数污染，即提交同一个参数名但多个值，或者尝试使用数组格式、JSON格式等（具体取决于后端解析逻辑）。但由于这是一个表单提交，我们首先尝试最直接的：修改请求体。

我们可以尝试将Body修改为：

authenticity_token=XXXX&user%5Bemail%5D=victim%40test.com&user%5Bemail%5D=attacker%40test.com

或者尝试不同的参数名组合，例如：

authenticity_token=XXXX&email=victim%40test.com&user%5Bemail%5D=attacker%40test.com

甚至尝试使用JSON格式（需要同时修改Content-Type头为application/json）：

{"user": {"email": ["victim@test.com", "attacker@test.com"]}}

这里就是需要反复测试和摸索的地方。漏洞的触发可能依赖于后端代码解析这些参数时的特定逻辑。你可能需要查阅公开的漏洞详情或分析补丁，来精确知道是哪个参数、以何种格式能被恶意利用。在我们的模拟复现中，假设我们发现当Body为authenticity_token=XXXX&user%5Bemail%5D[]=victim%40test.com&user%5Bemail%5D[]=attacker%40test.com（即传递一个数组）时，后端错误地将重置链接发送到了数组中的第二个邮箱（attacker@test.com）。

在Burp Suite中修改请求后，点击“Forward”发送。然后，去检查attacker@test.com的收件箱（可以是真实的邮箱，或者你在测试环境搭建的邮件服务器）。如果漏洞复现成功，你会在攻击者的邮箱里收到一封来自GitLab的密码重置邮件，而受害者邮箱则没有。这封邮件中的重置链接，将允许你直接为victim@test.com这个账户设置新密码，从而完成账户接管。

实操心得：Burp Suite的Repeater模块在这里非常有用。你可以将拦截到的初始请求发送到Repeater，然后在Repeater里反复修改参数、重放请求，同时观察响应和邮件接收情况，而无需在浏览器端重复操作。这能极大提高测试效率。

5. 关键数据流分析与Burp Suite截图解读

让我们结合假设成功的场景，分析一下Burp Suite抓取的关键数据包。首先看请求1：正常的密码重置请求（被拦截的原始请求）。截图会显示一个标准的POST请求，目标URL是http://your-gitlab-ip/users/password，请求体简单明了，只有一个user[email]参数。HTTP状态码通常是302重定向，跳转到提示邮件已发送的页面。

然后是请求2：被篡改后的恶意请求。这是我们在Burp Suite的Proxy或Repeater中修改后的请求。截图需要清晰展示我们是如何构造参数体的。例如，可能显示user[email][]参数出现了两次，或者展示了我们尝试的JSON结构。这个请求的响应可能也是302，从表面上看和正常请求没有区别，这正是漏洞的隐蔽之处——前端提示可能都是“重置链接已发送到您的邮箱”，但后端处理逻辑已经出错。

最关键的证据来自邮件接收结果。你需要展示两个邮箱的收件箱对比截图。受害者邮箱(victim@test.com)收件箱为空或没有GitLab重置邮件；而攻击者邮箱(attacker@test.com)的收件箱里赫然躺着一封“Reset your password”的邮件。邮件的发件人是GitLab，其中的重置链接指向类似http://your-gitlab-ip/users/password/edit?reset_password_token=XXXXX的地址。

最后，请求3：使用窃取到的令牌重置密码。点击攻击者邮箱中的链接，会引导浏览器向GitLab发起一个GET请求，获取密码重置表单。这个请求会携带reset_password_token参数。随后提交新密码的POST请求（到/users/password）也会包含这个令牌和新密码。Burp Suite截获这个POST请求，截图显示密码被成功修改。至此，整个账户接管流程完成。通过对比正常流程和漏洞利用流程的数据包，你可以清晰地看到攻击者是如何通过一个精心构造的请求，“欺骗”系统将重置令牌发送到了错误的地址。

6. 漏洞修复方案与安全加固建议

GitLab官方在后续版本中迅速修复了此漏洞。修复的核心在于加强了密码重置逻辑中对用户标识参数的验证。修补后的代码会确保：无论请求参数如何复杂，系统都只会识别并处理一个有效的、经过验证的邮箱地址，并且重置令牌必须发送到该账户预先注册且已验证的邮箱，完全杜绝了通过参数注入指定其他邮箱的可能性。

对于使用GitLab的企业或个人，安全加固措施非常直接：

1. 立即升级：检查你的GitLab版本，如果处于受影响范围，务必立即升级到已修复的安全版本。这是最根本、最有效的措施。
2. 审查日志：检查GitLab的日志（特别是production.log和auth.log），搜索是否有大量异常的密码重置请求，特别是针对同一用户或来自同一IP的请求，这可能是攻击尝试的痕迹。
3. 强化账户安全：启用双因素认证(2FA)。即使密码被重置，没有2FA设备也无法登录，能为账户增加一道坚固的防线。
4. 网络防护：在WAF（Web应用防火墙）或网关层面，可以配置规则，对/users/password这类敏感路径的POST请求进行检测，监控异常的参数格式或频繁的请求行为。

从开发和安全设计角度，这个漏洞也给我们提了个醒：对于身份验证、密码修改、邮箱绑定等核心安全功能，后端逻辑必须遵循“最小权限”和“明确验证”原则。任何用户提交的、用于标识身份的参数，都必须经过严格的、一对一的校验，避免出现多义性或被覆盖的可能。在处理用户输入时，特别是像邮箱这样的标识符，应该进行规范化处理，然后与数据库中的记录进行精确匹配，而不是简单地信任请求体中的某个字段。

7. 复现过程中的常见问题与排查技巧

在复现过程中，你可能会遇到一些问题。这里我记录了几个常见的坑和解决办法：

问题1：GitLab容器启动失败或无法访问。

• 排查：首先用docker ps查看容器是否在运行。如果没运行，用docker logs gitlab-test查看详细错误日志。常见的错误包括端口冲突（80、443端口被占用）、磁盘权限问题（挂载的volume目录权限不对）、或者内存不足（GitLab比较吃资源）。
• 解决：确保宿主机端口空闲；检查/srv/gitlab等挂载目录的权限，确保容器用户（通常是git）有读写权限；考虑给Docker分配更多内存（4GB或以上）。

问题2：Burp Suite抓不到HTTPS包。

• 排查：浏览器代理设置是否正确？Burp Suite的Proxy -> Intercept是否开启？是否在浏览器中安装了Burp Suite的CA证书？
• 解决：确保浏览器代理设置为127.0.0.1:8080；访问http://burp下载并安装CA证书；对于Firefox等浏览器，需要在其独立的证书管理中导入证书。

问题3：修改请求后，GitLab返回错误或行为不符合预期。

• 排查：authenticity_token是Rails框架的CSRF令牌，每次表单请求都可能不同。如果你在Repeater中重放旧的请求，这个令牌可能已过期。
• 解决：每次测试时，最好从浏览器发起一个新的重置请求并拦截，使用最新的authenticity_token。或者，在测试环境中暂时禁用CSRF保护（仅用于研究，生产环境绝不可行），但这需要修改GitLab配置，比较复杂。

问题4：收不到密码重置邮件。

• 排查：GitLab默认使用内置的Sendmail发送邮件，在测试环境中可能配置不当导致发送失败。
• 解决：查看GitLab容器的邮件日志/var/log/gitlab/mailroom/current或/var/log/gitlab/postfix/current。更简单的方法是，在GitLab管理后台配置一个外部SMTP服务器（如Gmail、SendGrid），或者使用mailcatcher、mailhog这类开发用的邮件拦截工具，它们会提供一个Web界面查看所有发出的邮件，非常适合漏洞复现测试。

问题5：无法确定确切的漏洞参数格式。

• 排查：公开的漏洞细节可能不会精确到请求体格式。不同版本、不同配置的GitLab，触发点可能略有差异。
• 解决：这是漏洞复现中最需要耐心和技巧的部分。除了尝试各种参数组合（数组、JSON、额外参数），还可以尝试对比打补丁前后的代码差异（GitLab是开源的）。关注PasswordResetsController相关的代码文件，看其中对email参数的处理逻辑是如何变化的。这能给你最准确的指引。

整个复现过程，本质上是一次对Web应用安全逻辑的深度探索。它要求你不仅会使用工具，更要理解数据如何流动，后端如何思考。当你成功触发了漏洞，并清晰地通过Burp Suite的截图看到攻击链的每一个环节时，你对这类“逻辑漏洞”的理解会比读十篇报告都深刻。安全研究，很多时候就是在这样的动手实践中，把抽象的原理变成具象的流量包，把模糊的风险变成清晰的复现步骤。