102 lines
4.2 KiB
Markdown
102 lines
4.2 KiB
Markdown
---
|
|
name: standard
|
|
description: Balanced security assessment with systematic methodology and full attack surface coverage
|
|
---
|
|
|
|
# Standard Testing Mode
|
|
|
|
Balanced security assessment with structured methodology. Thorough coverage without exhaustive depth.
|
|
|
|
## Approach
|
|
|
|
Systematic testing across the full attack surface. Understand the application before exploiting it.
|
|
|
|
## Phase 1: Reconnaissance
|
|
|
|
**Whitebox (source available)**
|
|
- Map codebase structure: modules, entry points, routing
|
|
- Start by loading existing `wiki` notes (`list_notes(category="wiki")` then `get_note(note_id=...)`) and update one shared repo note as mapping evolves
|
|
- Run `semgrep` first-pass triage to prioritize risky flows before deep manual review
|
|
- Run at least one AST-structural mapping pass (`sg` and/or Tree-sitter), then use outputs for route, sink, and trust-boundary mapping
|
|
- Keep AST output bounded to relevant paths and hypotheses; avoid whole-repo generic function dumps
|
|
- Identify architecture pattern (MVC, microservices, monolith)
|
|
- Trace input vectors: forms, APIs, file uploads, headers, cookies
|
|
- Review authentication and authorization flows
|
|
- Analyze database interactions and ORM usage
|
|
- Check dependencies and repo risks with `trivy fs`, `gitleaks`, and `trufflehog`
|
|
- Understand the data model and sensitive data locations
|
|
- Before completion, update the shared repo wiki with source findings summary and dynamic validation next steps
|
|
|
|
**Blackbox (no source)**
|
|
- Crawl application thoroughly, interact with every feature
|
|
- Enumerate endpoints, parameters, and functionality
|
|
- Fingerprint technology stack
|
|
- Map user roles and access levels
|
|
- Capture traffic with proxy to understand request/response patterns
|
|
|
|
## Phase 2: Business Logic Analysis
|
|
|
|
Before testing for vulnerabilities, understand the application:
|
|
|
|
- **Critical flows** - payments, registration, data access, admin functions
|
|
- **Role boundaries** - what actions are restricted to which users
|
|
- **Data access rules** - what data should be isolated between users
|
|
- **State transitions** - order lifecycle, account status changes
|
|
- **Trust boundaries** - where does privilege or sensitive data flow
|
|
|
|
## Phase 3: Systematic Testing
|
|
|
|
Test each attack surface methodically. Spawn focused subagents for different areas.
|
|
|
|
**Input Validation**
|
|
- Injection testing on all input fields (SQL, XSS, command, template)
|
|
- File upload bypass attempts
|
|
- Search and filter parameter manipulation
|
|
- Redirect and URL parameter handling
|
|
|
|
**Authentication & Session**
|
|
- Brute force protection
|
|
- Session token entropy and handling
|
|
- Password reset flow analysis
|
|
- Logout session invalidation
|
|
- Authentication bypass techniques
|
|
|
|
**Access Control**
|
|
- Horizontal: user A accessing user B's resources
|
|
- Vertical: unprivileged user accessing admin functions
|
|
- API endpoints vs UI access control consistency
|
|
- Direct object reference manipulation
|
|
|
|
**Business Logic**
|
|
- Multi-step process bypass (skip steps, reorder)
|
|
- Race conditions on state-changing operations
|
|
- Boundary conditions: negative values, zero, extremes
|
|
- Transaction replay and manipulation
|
|
|
|
## Phase 4: Exploitation
|
|
|
|
- Every finding requires a working proof-of-concept
|
|
- Demonstrate actual impact, not theoretical risk
|
|
- Chain vulnerabilities to show maximum severity
|
|
- Document full attack path from entry to impact
|
|
- Use python tool for complex exploit development
|
|
|
|
## Phase 5: Reporting
|
|
|
|
- Document all confirmed vulnerabilities with reproduction steps
|
|
- Severity based on exploitability and business impact
|
|
- Remediation recommendations
|
|
- Note areas requiring further investigation
|
|
|
|
## Chaining
|
|
|
|
Always ask: "If I can do X, what does that enable next?" Keep pivoting until reaching maximum privilege or data exposure.
|
|
|
|
Prefer complete end-to-end paths (entry point → pivot → privileged action/data) over isolated findings. Use the application as a real user would—exploit must survive actual workflow and state transitions.
|
|
|
|
When you discover a useful pivot (info leak, weak boundary, partial access), immediately pursue the next step rather than stopping at the first win.
|
|
|
|
## Mindset
|
|
|
|
Methodical and systematic. Document as you go. Validate everything—no assumptions about exploitability. Think about business impact, not just technical severity.
|