Src Auth Bypass

TL;DR

• 目的：Horizontal and vertical privilege escalation / authorization bypass testing (IDOR, BOLA, broken access control) across scoped applications…
• 适用：辅助/通用
• 输入：目标应用 + 鉴权架构描述
• 输出：认证 POC（截图 + 请求响应）+ 影响面（账户数量）+ 修复建议
• 红线：仅限授权范围内；扫描限速 -c 10 -rl 10；所有动作记 oplog
• 关联：上游：003-src-session-start → 下游：003-src-session-start（按需调用）

Workflow

1. Map authentication — Identify login flow (form/OAuth/SAML/API key)
2. Credential discovery — Default creds, leaked creds, brute force (with confirm)
3. Session analysis — Token entropy, expiration, fixation, CSRF
4. Auth bypass attempts — Direct object reference, type juggling, race
5. SAML specific — Signature stripping, XXE in assertion, XSW attacks
6. OAuth specific — redirect_uri abuse, scope escalation, token theft
7. Verification — Run 111-fp-check for cross-tool confirmation
8. Documentation — Per-auth-flow findings with reproduction

Common Bypass Vectors

• Authentication bypass — SQLi in login, NoSQL injection, LDAP injection
• Authorization bypass — IDOR, missing function-level checks
• Session management — Predictable tokens, missing expiration, fixation
• Credential recovery — Password reset poisoning, default credentials
• Multi-factor bypass — Race conditions, response manipulation, OTP leakage

When to Use

• Target presents indicators of the vulnerability class this skill covers
• Fingerprint or recon indicates the relevant technology stack is in use
• Authorized testing scope covers the target endpoint or component
• Findings need to be validated through this skill's methodology

When NOT to Use

• Target is clearly outside this skill's scope (refer to other web-vulns skills)
• No authorization for testing
• Need reconnaissance rather than exploitation (use 1-recon-osint skills instead)

SRC Authorization Bypass Testing

Quick Start

# 识别认证端点
grep -rn "auth\|login\|token" src/ | head -20
# 检查认证实现
grep -rn "verify\|validate\|jwt\|session" src/ | head -20

Objective

Find horizontal (user A -> user B data) and vertical (user -> admin) authorization flaws, especially in education platforms (grade, roster, personal data).

Workflow

1. Map Authorization Surface

• From asset map: user-facing APIs (REST/GraphQL/gRPC), pages with object references (student ID, order ID, attachment ID).
• Register two test accounts where possible (A and B) to prove cross-account access.

2. Horizontal Testing (IDOR/BOLA)

• Identify object IDs (numeric, UUID, barcode) in URLs, JSON bodies, headers.
• Access A's object with B's session; try enumeration patterns (+1, random UUID).
• API focus: BOLA (object-level) — PUT/DELETE/GET on other users' resources.
• GraphQL: check aliases / field-level access on nested objects.

3. Vertical Testing (Privilege Escalation)

• Role-based checks: student token calling admin endpoints; change role field in request/response (client-side trust).
• Admin-only paths discovered from JS bundles (API route maps).
• Forgot-password / account-recovery flows (another user's token).

4. Mass Assignment

• Add unexpected fields (role=admin, isAdmin=true) in update requests.

5. Verification & Evidence

• Confirm with two distinct accounts; capture: request pair (B reads A), response containing A's unique data (e.g., A's student number), timestamps.
• Severity: data sensitivity determines level (student PII high; public info low).

Red Lines

• No data bulk extraction; read-only proof (do not modify other users' data).
• Do not log into other accounts with recovered credentials (report instead).
• Log to /root/dig/audit/oplog.md.

Advanced Techniques

Multi-Session Coordination

Use multiple agent sessions in parallel for different scopes (e.g., one per target subdomain) with shared share/intel/ directory.

Session Persistence

Maintain session state in dig/<agent>/sessions/<target>-<timestamp>/ with notes.md, findings.md, screenshots/ subdirectories.