supabase-audit-authenticated
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseAuthenticated User Audit
已认证用户审计
🔴 CRITICAL: PROGRESSIVE FILE UPDATES REQUIREDYou MUST write to context files AS YOU GO, not just at the end.
- Write to
IMMEDIATELY after each test.sb-pentest-context.json- Log to
BEFORE and AFTER each action.sb-pentest-audit.log- DO NOT wait until the skill completes to update files
- If the skill crashes or is interrupted, all prior findings must already be saved
This is not optional. Failure to write progressively is a critical error.
This skill creates a test user (with explicit permission) to compare authenticated vs anonymous access and detect IDOR vulnerabilities.
🔴 重要提示:需要逐步更新文件你必须逐步写入上下文文件,而不是只在最后一次性写入。
- 每次测试完成后立即写入
.sb-pentest-context.json- 每次操作前后都要记录到
.sb-pentest-audit.log- 不要等到技能完成后再更新文件
- 如果技能崩溃或中断,所有已发现的结果必须已保存
这不是可选要求。不逐步写入文件属于严重错误。
本技能会在获得明确许可的情况下创建测试用户,对比已认证用户与匿名用户的访问权限,检测IDOR漏洞。
⚠️ IMPORTANT: User Consent Required
⚠️ 重要提示:需获得用户同意
╔═══════════════════════════════════════════════════════════════════╗
║ 🔐 USER CREATION CONSENT REQUIRED ║
╠═══════════════════════════════════════════════════════════════════╣
║ ║
║ This skill will CREATE A TEST USER in your Supabase project. ║
║ ║
║ The user will be created with: ║
║ • Email: pentest-[random]@security-audit.local ║
║ • Password: Strong random password (32+ chars) ║
║ • Purpose: Testing authenticated access vs anonymous ║
║ ║
║ At the end of the audit, you will be asked if you want to ║
║ DELETE the test user (recommended). ║
║ ║
║ Do you authorize the creation of a test user? ║
║ Type "yes, create test user" to proceed. ║
║ ║
╚═══════════════════════════════════════════════════════════════════╝DO NOT proceed without explicit user consent.
╔═══════════════════════════════════════════════════════════════════╗
║ 🔐 需要用户同意才能创建用户 ║
╠═══════════════════════════════════════════════════════════════════╣
║ ║
║ 该技能将在你的Supabase项目中**创建一个测试用户**。 ║
║ ║
║ 该用户的信息如下: ║
║ • 邮箱格式:pentest-[随机字符串]@security-audit.local ║
║ • 密码:强随机密码(32位以上) ║
║ • 用途:测试已认证用户与匿名用户的访问权限差异 ║
║ ║
║ 审计结束后,会询问你是否要**删除**该测试用户(推荐操作)。 ║
║ ║
║ 是否授权创建测试用户? ║
║ 请输入"yes, create test user"以继续。 ║
║ ║
╚═══════════════════════════════════════════════════════════════════╝未获得用户明确同意前请勿继续。
When to Use This Skill
何时使用该技能
- After completing anonymous access tests
- To detect IDOR (Insecure Direct Object Reference) vulnerabilities
- To test cross-user data access
- To verify RLS policies work for authenticated users
- To find privilege escalation issues
- 完成匿名用户访问测试后
- 检测IDOR(不安全直接对象引用)漏洞
- 测试跨用户数据访问权限
- 验证RLS策略对已认证用户是否生效
- 排查权限提升问题
Prerequisites
前置条件
- Signup must be open (or use invite flow)
- Anon key available
- Anonymous audit completed (recommended)
- 注册功能已开放(或可使用邀请流程)
- 已获取匿名密钥(Anon key)
- 已完成匿名用户审计(推荐)
Why Authenticated Testing Matters
已认证用户测试的重要性
Many vulnerabilities only appear with authentication:
| Vulnerability | Anonymous | Authenticated |
|---|---|---|
| RLS bypass (no RLS) | ✓ Detectable | ✓ Detectable |
| IDOR | ✗ Not visible | ✓ Only visible |
| Cross-user access | ✗ Not visible | ✓ Only visible |
| Privilege escalation | ✗ Not visible | ✓ Only visible |
| Overly permissive RLS | Partial | ✓ Full detection |
许多漏洞仅在用户认证后才会显现:
| 漏洞类型 | 匿名用户场景 | 已认证用户场景 |
|---|---|---|
| RLS绕过(未启用RLS) | ✓ 可检测 | ✓ 可检测 |
| IDOR | ✗ 不可见 | ✓ 仅在此场景可见 |
| 跨用户访问 | ✗ 不可见 | ✓ 仅在此场景可见 |
| 权限提升 | ✗ 不可见 | ✓ 仅在此场景可见 |
| 过度宽松的RLS策略 | 部分可检测 | ✓ 可完全检测 |
Test User Creation
测试用户创建规则
Email Format
邮箱格式
pentest-[8-char-random]@security-audit.localExample:
pentest-a7b3c9d2@security-audit.localpentest-[8位随机字符串]@security-audit.local示例:
pentest-a7b3c9d2@security-audit.localPassword Generation
密码生成规则
Strong password with:
- 32+ characters
- Uppercase, lowercase, numbers, symbols
- Cryptographically random
Example:
Xk9$mP2#vL5@nQ8&jR4*wY7!hT3%bU6^The password is displayed ONCE and saved to evidence.
强密码需满足:
- 32位以上字符
- 包含大小写字母、数字、符号
- 采用加密安全的随机算法生成
示例:
Xk9$mP2#vL5@nQ8&jR4*wY7!hT3%bU6^密码仅显示一次并保存到证据文件中。
Tests Performed
执行的测试内容
1. User Creation & Login
1. 用户创建与登录
bash
undefinedbash
undefinedCreate user
创建用户
curl -X POST "$SUPABASE_URL/auth/v1/signup"
-H "apikey: $ANON_KEY"
-H "Content-Type: application/json"
-d '{"email": "pentest-xxx@security-audit.local", "password": "[STRONG_PASSWORD]"}'
-H "apikey: $ANON_KEY"
-H "Content-Type: application/json"
-d '{"email": "pentest-xxx@security-audit.local", "password": "[STRONG_PASSWORD]"}'
curl -X POST "$SUPABASE_URL/auth/v1/signup"
-H "apikey: $ANON_KEY"
-H "Content-Type: application/json"
-d '{"email": "pentest-xxx@security-audit.local", "password": "[STRONG_PASSWORD]"}'
-H "apikey: $ANON_KEY"
-H "Content-Type: application/json"
-d '{"email": "pentest-xxx@security-audit.local", "password": "[STRONG_PASSWORD]"}'
Login and get JWT
登录并获取JWT
curl -X POST "$SUPABASE_URL/auth/v1/token?grant_type=password"
-H "apikey: $ANON_KEY"
-H "Content-Type: application/json"
-d '{"email": "pentest-xxx@security-audit.local", "password": "[STRONG_PASSWORD]"}'
-H "apikey: $ANON_KEY"
-H "Content-Type: application/json"
-d '{"email": "pentest-xxx@security-audit.local", "password": "[STRONG_PASSWORD]"}'
undefinedcurl -X POST "$SUPABASE_URL/auth/v1/token?grant_type=password"
-H "apikey: $ANON_KEY"
-H "Content-Type: application/json"
-d '{"email": "pentest-xxx@security-audit.local", "password": "[STRONG_PASSWORD]"}'
-H "apikey: $ANON_KEY"
-H "Content-Type: application/json"
-d '{"email": "pentest-xxx@security-audit.local", "password": "[STRONG_PASSWORD]"}'
undefined2. Authenticated vs Anonymous Comparison
2. 已认证用户与匿名用户权限对比
For each table:
| Test | Anonymous | Authenticated | Finding |
|---|---|---|---|
| SELECT | 0 rows | 1,247 rows | 🔴 Auth-only exposure |
| Own data | N/A | Only own row | ✅ RLS working |
| Other users' data | N/A | All rows | 🔴 Cross-user access |
针对每个数据表执行以下对比:
| 测试项 | 匿名用户 | 已认证用户 | 检测结果 |
|---|---|---|---|
| SELECT操作 | 0行数据 | 1247行数据 | 🔴 仅认证用户可访问的敏感数据 |
| 自身数据访问 | 不适用 | 仅能访问自身数据 | ✅ RLS策略生效 |
| 其他用户数据访问 | 不适用 | 可访问所有用户数据 | 🔴 跨用户访问漏洞 |
3. IDOR Testing
3. IDOR漏洞测试
bash
undefinedbash
undefinedAs test user, try to access other user's data
使用测试用户尝试访问其他用户的数据
curl "$SUPABASE_URL/rest/v1/orders?user_id=eq.[OTHER_USER_ID]"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [TEST_USER_JWT]"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [TEST_USER_JWT]"
curl "$SUPABASE_URL/rest/v1/orders?user_id=eq.[OTHER_USER_ID]"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [TEST_USER_JWT]"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [TEST_USER_JWT]"
If returns data: IDOR vulnerability!
如果返回数据:存在IDOR漏洞!
undefinedundefined4. Cross-User Access
4. 跨用户访问测试
bash
undefinedbash
undefinedGet test user's ID from JWT
从JWT中获取测试用户ID
TEST_USER_ID=$(echo $JWT | jq -r '.sub')
TEST_USER_ID=$(echo $JWT | jq -r '.sub')
Try to access data belonging to a different user
尝试访问其他用户的数据
curl "$SUPABASE_URL/rest/v1/profiles?id=neq.$TEST_USER_ID"
-H "Authorization: Bearer [TEST_USER_JWT]"
-H "Authorization: Bearer [TEST_USER_JWT]"
curl "$SUPABASE_URL/rest/v1/profiles?id=neq.$TEST_USER_ID"
-H "Authorization: Bearer [TEST_USER_JWT]"
-H "Authorization: Bearer [TEST_USER_JWT]"
If returns other users' profiles: Cross-user access!
如果返回其他用户的信息:存在跨用户访问漏洞!
undefinedundefined5. Storage with Authentication
5. 带认证的存储服务测试
bash
undefinedbash
undefinedTest authenticated storage access
测试已认证用户的存储服务访问权限
curl "$SUPABASE_URL/storage/v1/object/list/documents"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [TEST_USER_JWT]"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [TEST_USER_JWT]"
curl "$SUPABASE_URL/storage/v1/object/list/documents"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [TEST_USER_JWT]"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [TEST_USER_JWT]"
Compare with anonymous results
与匿名用户的测试结果对比
undefinedundefined6. Realtime with Authentication
6. 带认证的实时服务测试
javascript
// Subscribe to table changes as authenticated user
const channel = supabase.channel('test')
.on('postgres_changes', {
event: '*',
schema: 'public',
table: 'orders'
}, payload => console.log(payload))
.subscribe()
// Does it receive OTHER users' order changes?javascript
undefinedOutput Format
以已认证用户身份订阅数据表变更
═══════════════════════════════════════════════════════════
AUTHENTICATED USER AUDIT
═══════════════════════════════════════════════════════════
─────────────────────────────────────────────────────────
Test User Creation
─────────────────────────────────────────────────────────
Status: ✅ User created successfully
Test User Details:
├── Email: pentest-a7b3c9d2@security-audit.local
├── User ID: 550e8400-e29b-41d4-a716-446655440099
├── Password: [Saved to evidence - shown once]
└── JWT obtained: ✅
─────────────────────────────────────────────────────────
Anonymous vs Authenticated Comparison
─────────────────────────────────────────────────────────
Table: users
├── Anonymous access: 0 rows
├── Authenticated access: 1,247 rows ← ALL USERS!
└── Status: 🔴 P0 - Data hidden from anon but exposed to any auth user
Table: orders
├── Anonymous access: 0 rows (blocked)
├── Authenticated access: 1 row (own orders only)
└── Status: ✅ RLS working correctly
Table: profiles
├── Anonymous access: 0 rows
├── Authenticated access: 1,247 rows ← ALL PROFILES!
├── Own profile only expected: ❌ NO
└── Status: 🔴 P0 - Cross-user profile access
─────────────────────────────────────────────────────────
IDOR Testing
─────────────────────────────────────────────────────────
Test: Access other user's orders by ID
├── Request: GET /orders?user_id=eq.[other-user-id]
├── Auth: Test user JWT
├── Response: 200 OK - 15 orders returned
└── Status: 🔴 P0 - IDOR VULNERABILITY
Proof:
curl "$URL/rest/v1/orders?user_id=eq.other-user-uuid" \
-H "Authorization: Bearer [test-user-jwt]"
# Returns orders belonging to other-user-uuid!
Test: Access admin endpoints
├── Request: GET /functions/v1/admin-panel
├── Auth: Test user JWT (regular user)
├── Response: 200 OK - Admin data returned!
└── Status: 🔴 P0 - PRIVILEGE ESCALATION
─────────────────────────────────────────────────────────
Storage with Authentication
─────────────────────────────────────────────────────────
Bucket: documents
├── Anonymous: ❌ 0 files (blocked)
├── Authenticated: ✅ 523 files visible ← ALL USERS' FILES!
└── Status: 🔴 P1 - Auth users see all documents
Bucket: user-uploads
├── Anonymous: ❌ 0 files
├── Authenticated: 3 files (own files only)
└── Status: ✅ RLS working correctly
─────────────────────────────────────────────────────────
Summary
─────────────────────────────────────────────────────────
New Findings (Auth-only):
├── 🔴 P0: users table - all users visible to any auth user
├── 🔴 P0: profiles table - cross-user access
├── 🔴 P0: IDOR in orders - can access any user's orders
├── 🔴 P0: Privilege escalation in admin-panel
└── 🟠 P1: documents bucket - all files visible to auth users
Comparison:
├── Issues found (Anonymous): 3
├── Issues found (Authenticated): 8 ← 5 NEW ISSUES!
└── Auth-only vulnerabilities: 5
Recommendation:
These issues were NOT visible in anonymous testing!
Always test with authenticated users.
─────────────────────────────────────────────────────────
Cleanup
─────────────────────────────────────────────────────────
⚠️ Test user still exists in database.
Do you want to delete the test user?
Email: pentest-a7b3c9d2@security-audit.local
[This requires service_role key or manual deletion]
═══════════════════════════════════════════════════════════const channel = supabase.channel('test')
.on('postgres_changes', {
event: '*',
schema: 'public',
table: 'orders'
}, payload => console.log(payload))
.subscribe()
Context Output
是否能接收到其他用户的订单变更通知?
json
{
"authenticated_audit": {
"timestamp": "2025-01-31T12:00:00Z",
"test_user": {
"email": "pentest-a7b3c9d2@security-audit.local",
"user_id": "550e8400-e29b-41d4-a716-446655440099",
"created_at": "2025-01-31T12:00:00Z",
"deleted": false
},
"comparison": {
"tables": {
"users": {
"anon_access": 0,
"auth_access": 1247,
"expected_auth_access": "own_row_only",
"severity": "P0",
"finding": "All users visible to any authenticated user"
},
"orders": {
"anon_access": 0,
"auth_access": 1,
"expected_auth_access": "own_rows_only",
"severity": null,
"finding": "RLS working correctly"
}
},
"idor_tests": [
{
"test": "access_other_user_orders",
"vulnerable": true,
"severity": "P0",
"proof": "curl command..."
}
],
"privilege_escalation": [
{
"endpoint": "/functions/v1/admin-panel",
"vulnerable": true,
"severity": "P0"
}
]
},
"summary": {
"anon_issues": 3,
"auth_issues": 8,
"auth_only_issues": 5
}
}
}undefinedRLS Policy Examples
输出格式
Correct: Users see only their own data
—
sql
-- This RLS policy is correct
CREATE POLICY "Users see own data"
ON users FOR SELECT
USING (auth.uid() = id);
-- Result:
-- Anonymous: 0 rows
-- Authenticated: 1 row (own data)═══════════════════════════════════════════════════════════
已认证用户审计报告
═══════════════════════════════════════════════════════════
─────────────────────────────────────────────────────────
测试用户创建状态
─────────────────────────────────────────────────────────
状态:✅ 用户创建成功
测试用户详情:
├── 邮箱:pentest-a7b3c9d2@security-audit.local
├── 用户ID:550e8400-e29b-41d4-a716-446655440099
├── 密码:[已保存到证据文件 - 仅显示一次]
└── 已获取JWT:✅
─────────────────────────────────────────────────────────
匿名用户与已认证用户权限对比
─────────────────────────────────────────────────────────
数据表:users
├── 匿名用户访问:0行数据
├── 已认证用户访问:1247行数据 ← 所有用户数据!
└── 状态:🔴 P0级 - 匿名用户无法访问但任何已认证用户均可查看所有数据
数据表:orders
├── 匿名用户访问:0行数据(被拦截)
├── 已认证用户访问:1行数据(仅自身订单)
└── 状态:✅ RLS策略生效
数据表:profiles
├── 匿名用户访问:0行数据
├── 已认证用户访问:1247行数据 ← 所有用户资料!
├── 预期仅能访问自身资料:❌ 不符合
└── 状态:🔴 P0级 - 跨用户资料访问漏洞
─────────────────────────────────────────────────────────
IDOR漏洞测试
─────────────────────────────────────────────────────────
测试项:通过ID访问其他用户的订单
├── 请求:GET /orders?user_id=eq.[其他用户ID]
├── 认证方式:测试用户JWT
├── 响应:200 OK - 返回15条订单数据
└── 状态:🔴 P0级 - IDOR漏洞
证据:
curl "$URL/rest/v1/orders?user_id=eq.other-user-uuid" \
-H "Authorization: Bearer [test-user-jwt]"
# 返回了属于other-user-uuid的订单数据!
测试项:访问管理员端点
├── 请求:GET /functions/v1/admin-panel
├── 认证方式:测试用户JWT(普通用户)
├── 响应:200 OK - 返回管理员数据!
└── 状态:🔴 P0级 - 权限提升漏洞
─────────────────────────────────────────────────────────
带认证的存储服务测试
─────────────────────────────────────────────────────────
存储桶:documents
├── 匿名用户访问:❌ 0个文件(被拦截)
├── 已认证用户访问:✅ 523个文件可见 ← 所有用户的文件!
└── 状态:🔴 P1级 - 已认证用户可查看所有文档
存储桶:user-uploads
├── 匿名用户访问:❌ 0个文件
├── 已认证用户访问:3个文件(仅自身文件)
└── 状态:✅ RLS策略生效
─────────────────────────────────────────────────────────
总结
─────────────────────────────────────────────────────────
新发现的漏洞(仅在认证场景下):
├── 🔴 P0级:users表 - 任何已认证用户均可查看所有用户数据
├── 🔴 P0级:profiles表 - 跨用户访问漏洞
├── 🔴 P0级:orders表存在IDOR漏洞
├── 🔴 P0级:admin-panel端点存在权限提升漏洞
└── 🟠 P1级:documents存储桶 - 所有文件对已认证用户可见
对比结果:
├── 匿名用户场景发现漏洞:3个
├── 已认证用户场景发现漏洞:8个 ← 新增5个漏洞!
└── 仅在认证场景下存在的漏洞:5个
建议:
这些漏洞在匿名用户测试中无法被发现!
务必对已认证用户场景进行测试。
─────────────────────────────────────────────────────────
清理操作
─────────────────────────────────────────────────────────
⚠️ 测试用户仍存在于数据库中。
是否要删除测试用户?
邮箱:pentest-a7b3c9d2@security-audit.local
[需要service_role密钥或手动删除]
═══════════════════════════════════════════════════════════Incorrect: All authenticated users see everything
上下文输出格式
sql
-- This RLS policy is WRONG
CREATE POLICY "Authenticated users see all"
ON users FOR SELECT
USING (auth.role() = 'authenticated'); -- ❌ Too permissive!
-- Result:
-- Anonymous: 0 rows
-- Authenticated: ALL rows ← VULNERABILITY!json
{
"authenticated_audit": {
"timestamp": "2025-01-31T12:00:00Z",
"test_user": {
"email": "pentest-a7b3c9d2@security-audit.local",
"user_id": "550e8400-e29b-41d4-a716-446655440099",
"created_at": "2025-01-31T12:00:00Z",
"deleted": false
},
"comparison": {
"tables": {
"users": {
"anon_access": 0,
"auth_access": 1247,
"expected_auth_access": "own_row_only",
"severity": "P0",
"finding": "所有已认证用户均可查看所有用户数据"
},
"orders": {
"anon_access": 0,
"auth_access": 1,
"expected_auth_access": "own_rows_only",
"severity": null,
"finding": "RLS策略生效"
}
},
"idor_tests": [
{
"test": "access_other_user_orders",
"vulnerable": true,
"severity": "P0",
"proof": "curl命令..."
}
],
"privilege_escalation": [
{
"endpoint": "/functions/v1/admin-panel",
"vulnerable": true,
"severity": "P0"
}
]
},
"summary": {
"anon_issues": 3,
"auth_issues": 8,
"auth_only_issues": 5
}
}
}Correct fix:
RLS策略示例
—
正确示例:用户仅能查看自身数据
sql
-- Fix: Add user ownership check
CREATE POLICY "Users see own data"
ON users FOR SELECT
USING (auth.uid() = id); -- ✅ Only own rowsql
-- 该RLS策略配置正确
CREATE POLICY "Users see own data"
ON users FOR SELECT
USING (auth.uid() = id);
-- 结果:
-- 匿名用户:0行数据
-- 已认证用户:1行数据(仅自身数据)Cleanup Options
错误示例:所有已认证用户可查看全部数据
Option 1: Manual deletion (Dashboard)
—
Supabase Dashboard → Authentication → Users → Find test user → Deletesql
-- 该RLS策略配置错误
CREATE POLICY "Authenticated users see all"
ON users FOR SELECT
USING (auth.role() = 'authenticated'); -- ❌ 权限过于宽松!
-- 结果:
-- 匿名用户:0行数据
-- 已认证用户:所有行数据 ← 存在漏洞!Option 2: Via service_role key (if available)
正确修复方案:
bash
curl -X DELETE "$SUPABASE_URL/auth/v1/admin/users/[USER_ID]" \
-H "apikey: $SERVICE_ROLE_KEY" \
-H "Authorization: Bearer $SERVICE_ROLE_KEY"sql
-- 修复:添加用户归属校验
CREATE POLICY "Users see own data"
ON users FOR SELECT
USING (auth.uid() = id); -- ✅ 仅能访问自身数据Option 3: Leave for later
清理测试用户的方式
—
方式1:手动删除(通过控制台)
The test user uses a non-functional email domain () and cannot be used maliciously.
security-audit.localSupabase控制台 → 认证 → 用户 → 找到测试用户 → 删除MANDATORY: Evidence Collection
方式2:使用service_role密钥删除(若可用)
📁 Evidence Directory:
.sb-pentest-evidence/05-auth-audit/authenticated-tests/bash
curl -X DELETE "$SUPABASE_URL/auth/v1/admin/users/[USER_ID]" \
-H "apikey: $SERVICE_ROLE_KEY" \
-H "Authorization: Bearer $SERVICE_ROLE_KEY"Evidence Files to Create
方式3:留待后续处理
| File | Content |
|---|---|
| Test user details (password saved securely) |
| Side-by-side comparison |
| IDOR test results |
| Privilege escalation tests |
测试用户使用的是无效邮箱域名(),不会被恶意利用。
security-audit.localEvidence Format
强制要求:证据收集
json
{
"evidence_id": "AUTH-TEST-001",
"timestamp": "2025-01-31T12:00:00Z",
"category": "auth-audit",
"type": "authenticated_testing",
"test_user": {
"email": "pentest-a7b3c9d2@security-audit.local",
"user_id": "550e8400-...",
"password": "[STORED SECURELY - DO NOT COMMIT]"
},
"comparison_test": {
"table": "users",
"anonymous": {
"curl_command": "curl '$URL/rest/v1/users' -H 'apikey: $ANON_KEY'",
"response_status": 200,
"rows_returned": 0
},
"authenticated": {
"curl_command": "curl '$URL/rest/v1/users' -H 'apikey: $ANON_KEY' -H 'Authorization: Bearer $JWT'",
"response_status": 200,
"rows_returned": 1247
},
"finding": {
"severity": "P0",
"issue": "All users visible to any authenticated user",
"expected": "Only own row should be visible",
"impact": "Full user enumeration for any authenticated user"
}
}
}📁 证据目录:
.sb-pentest-evidence/05-auth-audit/authenticated-tests/Add to curl-commands.sh
需要创建的证据文件
bash
undefined| 文件名称 | 内容 |
|---|---|
| 测试用户详情(密码已安全存储) |
| 匿名用户与已认证用户的权限对比结果 |
| IDOR漏洞测试结果 |
| 权限提升漏洞测试结果 |
=== AUTHENTICATED TESTING ===
证据文件格式
NOTE: Replace [JWT] with test user's JWT
—
Compare anonymous vs authenticated access
—
curl -s "$SUPABASE_URL/rest/v1/users?select=&limit=5" -H "apikey: $ANON_KEY"
curl -s "$SUPABASE_URL/rest/v1/users?select=&limit=5" -H "apikey: $ANON_KEY" -H "Authorization: Bearer [JWT]"
json
{
"evidence_id": "AUTH-TEST-001",
"timestamp": "2025-01-31T12:00:00Z",
"category": "auth-audit",
"type": "authenticated_testing",
"test_user": {
"email": "pentest-a7b3c9d2@security-audit.local",
"user_id": "550e8400-...",
"password": "[已安全存储 - 请勿提交到版本控制系统]"
},
"comparison_test": {
"table": "users",
"anonymous": {
"curl_command": "curl '$URL/rest/v1/users' -H 'apikey: $ANON_KEY'",
"response_status": 200,
"rows_returned": 0
},
"authenticated": {
"curl_command": "curl '$URL/rest/v1/users' -H 'apikey: $ANON_KEY' -H 'Authorization: Bearer $JWT'",
"response_status": 200,
"rows_returned": 1247
},
"finding": {
"severity": "P0",
"issue": "所有已认证用户均可查看所有用户数据",
"expected": "仅能查看自身数据",
"impact": "任何已认证用户均可枚举所有用户信息"
}
}
}IDOR test - access other user's data
添加到curl-commands.sh
curl -s "$SUPABASE_URL/rest/v1/orders?user_id=eq.[OTHER_USER_ID]"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [JWT]"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [JWT]"
bash
undefinedCross-user profile access
=== 已认证用户测试 ===
—
注意:将[JWT]替换为测试用户的JWT
—
对比匿名用户与已认证用户的访问权限
curl -s "$SUPABASE_URL/rest/v1/profiles?id=neq.[TEST_USER_ID]"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [JWT]"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [JWT]"
undefinedcurl -s "$SUPABASE_URL/rest/v1/users?select=&limit=5" -H "apikey: $ANON_KEY"
curl -s "$SUPABASE_URL/rest/v1/users?select=&limit=5" -H "apikey: $ANON_KEY" -H "Authorization: Bearer [JWT]"
MANDATORY: Progressive Context File Updates
IDOR漏洞测试 - 访问其他用户的数据
⚠️ This skill MUST update tracking files PROGRESSIVELY during execution, NOT just at the end.
curl -s "$SUPABASE_URL/rest/v1/orders?user_id=eq.[OTHER_USER_ID]"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [JWT]"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [JWT]"
Critical Rule: Write As You Go
跨用户资料访问测试
DO NOT batch all writes at the end. Instead:
- Before user creation → Log consent and action to
.sb-pentest-audit.log - After user created → Immediately save user details to context and evidence
- After each comparison test → Update with results
.sb-pentest-context.json - After each IDOR test → Save evidence immediately
This ensures that if the skill is interrupted, crashes, or times out, all findings up to that point are preserved.
curl -s "$SUPABASE_URL/rest/v1/profiles?id=neq.[TEST_USER_ID]"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [JWT]"
-H "apikey: $ANON_KEY"
-H "Authorization: Bearer [JWT]"
undefinedRequired Actions (Progressive)
强制要求:逐步更新上下文文件
-
Log user creation:
[TIMESTAMP] [supabase-audit-authenticated] [CONSENT] User authorized test user creation [TIMESTAMP] [supabase-audit-authenticated] [CREATED] Test user pentest-xxx@security-audit.local -
Save test user to context immediately:json
{ "authenticated_audit": { "test_user": { "email": "...", "user_id": "...", "created_at": "..." } } } -
Log each finding as discovered:
[TIMESTAMP] [supabase-audit-authenticated] [FINDING] P0: IDOR in orders table
FAILURE TO UPDATE CONTEXT FILES PROGRESSIVELY IS NOT ACCEPTABLE.
⚠️ 该技能必须在执行过程中逐步更新跟踪文件,而非仅在最后一次性更新。
Related Skills
核心规则:逐步写入
- — Test if signup is open first
supabase-audit-auth-signup - — Compare with anonymous results
supabase-audit-tables-read - — Deep dive into RLS policies
supabase-audit-rls - — Test function access with auth
supabase-audit-functions - — Include auth-only findings in report
supabase-report
不要在最后批量写入。请按以下步骤操作:
- 创建用户前 → 将用户同意记录和操作记录到
.sb-pentest-audit.log - 用户创建后 → 立即将用户详情保存到上下文文件和证据文件
- 每次对比测试后 → 更新记录测试结果
.sb-pentest-context.json - 每次IDOR测试后 → 立即保存证据
这样可以确保如果技能被中断、崩溃或超时,截至当前的所有测试结果都已被保存。
—
必须执行的逐步操作
—
-
记录用户创建操作:
[时间戳] [supabase-audit-authenticated] [CONSENT] 用户已授权创建测试用户 [时间戳] [supabase-audit-authenticated] [CREATED] 已创建测试用户pentest-xxx@security-audit.local -
立即将测试用户信息保存到上下文文件:json
{ "authenticated_audit": { "test_user": { "email": "...", "user_id": "...", "created_at": "..." } } } -
发现漏洞后立即记录:
[时间戳] [supabase-audit-authenticated] [FINDING] P0级:orders表存在IDOR漏洞
不逐步更新上下文文件是不被允许的。
—
相关技能
—
- — 先测试注册功能是否开放
supabase-audit-auth-signup - — 与匿名用户测试结果对比
supabase-audit-tables-read - — 深入审计RLS策略
supabase-audit-rls - — 测试已认证用户的函数访问权限
supabase-audit-functions - — 在报告中包含仅在认证场景下发现的漏洞
supabase-report