Skip to main content
The proxy tester system is a set of nine agents that work together to analyze intercepted HTTP traffic and test each request for specific vulnerability classes. The proxy-agent orchestrates the others, selecting which testers to run based on the characteristics of each intercepted request.

​
How it works

1

Configure your HTTP proxy

Point your browser or mobile app to CyberStrike’s built-in HTTP proxy. The browser extension captures requests automatically, including the authenticated user context (cookies, Authorization headers) for each container.
2

Activate the proxy-agent

Switch to the proxy-agent in the TUI by pressing Tab, or pass --agent proxy-agent to the run command.
3

Browse your target application

Use the application normally — log in, navigate features, submit forms. Every request that passes through the proxy is forwarded to the proxy-agent for analysis.
4

Orchestration and analysis

For each intercepted request, the proxy-agent calls proxy-analyzer first to extract application architecture context (objects, roles, functions, object IDs, credential claims). It then queries the accumulated session context to understand what credentials and roles are available.
5

Intelligent tester selection

Based on the request characteristics and accumulated context, the proxy-agent selects which vulnerability testing agents to run in parallel. A POST endpoint with a JSON body and numeric IDs might trigger proxy-tester-injection, proxy-tester-idor, and proxy-tester-mass-assignment simultaneously.
6

Testing and reporting

Selected testers execute their test cases against the endpoint. Each tester calls report_vulnerability when it finds a confirmed finding. Results appear in the session sidebar in real time.

​
Agents

​
proxy-agent (orchestrator)

The proxy-agent is a pure orchestrator. It does not perform vulnerability testing itself. Its role is to:
  1. Receive raw HTTP requests from the browser extension with credential context
  2. Delegate architecture analysis to proxy-analyzer
  3. Review accumulated session context — credentials, roles, discovered objects and their IDs
  4. Select vulnerability testing agents intelligently based on request characteristics and session state
  5. Launch selected agents in parallel
  6. Process the re-test queue when new discoveries trigger additional testing
Permissions: web_get_session_context, question Selection logic: The agent uses dynamic analysis rather than rigid routing rules. A request with a url= parameter triggers SSRF testing. A POST with a JSON body triggers injection and mass assignment. A path containing a numeric ID triggers IDOR. Multiple credentials in session context increase the value of authorization testing.

​
proxy-tester-idor

Tests for Insecure Direct Object References by manipulating object identifiers in paths, query parameters, and request bodies. When it runs: The request contains numeric or UUID identifiers, the session has multiple credentials with cross-user object values, or the endpoint operates on user-specific resources. Also runs with a single credential by testing ID manipulation — sequential IDs, negative values, common IDs like 1 and 100, and admin IDs. What it tests:
  • Path parameter manipulation: /api/users/123 → /api/users/124, /api/users/1, /api/users/-1
  • Query parameter swapping between users: ?invoice_id=456 with a different user’s credential
  • Body field ID manipulation in POST/PUT requests
  • Cross-user object access using session credentials from multiple accounts
  • UUID guessing and prediction where applicable
Permissions: bash, webfetch, web_get_session_context, web_get_request_detail, report_vulnerability

​
proxy-tester-authz

Tests for authorization bypass and broken access control using discovered roles and credentials. When it runs: The session has multiple credentials with different privilege levels, the endpoint appears to require authentication or authorization, or the path indicates protected functionality. What it tests:
  • Vertical privilege escalation: accessing admin endpoints with a regular user credential
  • Horizontal privilege escalation: accessing another user’s resources with the same role
  • Authentication bypass: removing the Authorization header or session cookie entirely
  • Forced browsing: directly accessing endpoints that should be reachable only through a specific workflow
  • HTTP method-based access control flaws: GET /admin/users blocked but POST /admin/users allowed
  • Path-based bypass: /admin/users blocked but /Admin/users or /admin/./users allowed
Permissions: bash, webfetch, web_get_session_context, web_get_request_detail, report_vulnerability

​
proxy-tester-mass-assignment

Tests for mass assignment vulnerabilities by injecting additional fields into request bodies. When it runs: The endpoint accepts POST, PUT, or PATCH requests with a body, and the session has discovered objects with sensitive fields such as role, price, is_admin, discount, or status. What it tests:
  • Admin and role escalation: injecting "role": "admin" or "is_admin": true into registration or profile update requests
  • Status manipulation: injecting "status": "verified" or "approved": true
  • Financial field injection: injecting "price": 0, "discount": 100, or "credit": 9999
  • Ownership bypass: injecting "user_id": <other_user_id> to reassign resources
  • Nested field injection in complex JSON structures
Permissions: bash, webfetch, web_get_session_context, web_get_request_detail, report_vulnerability

​
proxy-tester-injection

Tests for all injection vulnerability classes across query parameters, request body fields, and headers. When it runs: The request accepts user-supplied input in any location — query parameters, JSON body fields, form fields, or headers. What it tests:
  • SQL injection — Error-based, union-based, blind boolean, and time-based SQLi across MySQL, PostgreSQL, Oracle, SQL Server, and NoSQL databases
  • XSS — Reflected and stored XSS via input parameters that are echoed in responses
  • Server-Side Template Injection (SSTI) — {{7*7}}, ${7*7}, <%= 7*7 %> in user input fields
  • XXE — XML external entity injection in XML content types
  • Command injection — ;id, |whoami, and backtick payloads in parameters processed by shell commands
  • LDAP injection — In search and authentication parameters
  • NoSQL injection — MongoDB operator injection ({"$gt":""}, {$ne:null})
Permissions: bash, webfetch, web_get_session_context, web_get_request_detail, report_vulnerability

​
proxy-tester-authn

Tests for authentication and session management vulnerabilities. When it runs: The endpoint handles authentication (login, SSO, MFA), manages sessions (logout, token refresh), or handles credentials (registration, password reset). Also runs on any endpoint where JWT tokens are present in the session context. What it tests:
  • JWT algorithm confusion — alg: none, weak HMAC secret brute force, RSA-to-HMAC key confusion
  • Authentication bypass — SQLi in login fields, parameter manipulation, direct access to post-auth pages
  • Session fixation — Pre-authentication session token persists after login
  • Brute force and credential stuffing — Rate limit enforcement on login endpoints
  • Password reset vulnerabilities — Predictable or reusable reset tokens, host header injection in reset emails
  • MFA bypass — OTP brute force, race conditions, fallback mechanism abuse
  • Session invalidation — Tokens remain valid after logout
Permissions: bash, webfetch, web_get_session_context, web_get_request_detail, report_vulnerability

​
proxy-tester-business-logic

Tests for business logic flaws in transactional and workflow-based endpoints. When it runs: The endpoint involves financial transactions, multi-step workflows, quantity-based operations, or rate-limited actions. What it tests:
  • Price manipulation — Setting total, price, or amount to zero, negative values, or integer overflow values
  • Negative quantities — Ordering -1 items to receive credits or bypass minimum purchase requirements
  • Workflow bypass — Accessing step 3 of a multi-step checkout without completing steps 1 and 2
  • Race conditions — Concurrent requests to apply a one-time coupon or trigger a transaction twice
  • Rate limit abuse — Bypassing request limits by manipulating headers (X-Forwarded-For), rotating user agents, or using parallel requests
  • Integer overflow — Values exceeding expected integer ranges to trigger unexpected behavior
Permissions: bash, webfetch, web_get_session_context, web_get_request_detail, report_vulnerability

​
proxy-tester-ssrf

Tests for Server-Side Request Forgery by exploiting URL parameters to reach internal infrastructure. When it runs: The endpoint accepts URL or URI parameters with names like url, link, webhook, callback, redirect, src, or fetch, or processes external resources. What it tests:
  • Cloud metadata endpoints — http://169.254.169.254/latest/meta-data/ (AWS), http://metadata.google.internal/ (GCP), http://169.254.169.254/metadata/ (Azure)
  • Internal network scanning — http://localhost, http://127.0.0.1, http://10.0.0.1, common internal IP ranges
  • Protocol smuggling — file:///etc/passwd, dict://, gopher:// protocol handlers
  • DNS rebinding — Detecting when server-side validation uses DNS but execution uses a different resolved IP
  • Blind SSRF — Out-of-band detection via Burp Collaborator-style callbacks when no response is returned
Permissions: bash, webfetch, web_get_session_context, web_get_request_detail, report_vulnerability

​
proxy-tester-file-attacks

Tests for file upload vulnerabilities, path traversal, and file inclusion attacks. When it runs: The endpoint accepts file uploads (multipart/form-data), has file path parameters, or processes user-supplied filenames. What it tests:
  • Malicious file type upload — Uploading web shells disguised as images, SVG files containing XSS payloads, DOCX files containing XXE
  • MIME type bypass — Changing the Content-Type header to bypass server-side validation while uploading executable files
  • Path traversal — ../../etc/passwd, ..%2F..%2Fetc%2Fpasswd, and null-byte injection in file path parameters
  • Zip slip — Crafted ZIP archives with directory traversal in filenames that extract to arbitrary paths
  • XXE via file upload — XML-based file formats (DOCX, XLSX, SVG) containing external entity references
  • File inclusion — Local File Inclusion (LFI) and Remote File Inclusion (RFI) via file path parameters
Permissions: bash, webfetch, web_get_session_context, web_get_request_detail, report_vulnerability

​
Tester selection matrix

The proxy-agent uses this decision framework when selecting agents for each request. Multiple agents run in parallel when applicable.
Request characteristicAgents triggered
Numeric or UUID ID in path / query / bodyproxy-tester-idor
POST / PUT / PATCH with a request bodyproxy-tester-injection, proxy-tester-mass-assignment
Authentication or session endpointproxy-tester-authn
Multiple credentials in session with different privilege levelsproxy-tester-authz
Financial or transactional fields (price, total, quantity)proxy-tester-business-logic
URL parameter (url=, webhook=, redirect=)proxy-tester-ssrf
File upload or file path parameterproxy-tester-file-attacks
Any user input reflected in responseproxy-tester-injection (XSS)
JWT token in session contextproxy-tester-authn
The proxy-agent launches applicable testers in parallel for each request, so a complex API endpoint may have five or six testers running simultaneously. Each tester self-assesses applicability and skips if the request clearly does not match its prerequisites.

​
Example workflows

cyberstrike run --agent proxy-agent \
  "Begin proxy testing session. I'll browse the app at https://app.example.com and you should test each intercepted request."
The proxy-analyzer and all proxy-tester-* agents are hidden from the agent switcher. They are internal sub-agents managed by proxy-agent. You interact only with proxy-agent directly.

Build docs developers (and LLMs) love

Get started for freeTalk to us