From 7daf6e0ad1143918f769454de6923a06c3812dcb Mon Sep 17 00:00:00 2001 From: aditya-arcot Date: Wed, 4 Mar 2026 19:24:48 -0600 Subject: [PATCH 1/3] fix title & cleanup whitespace --- prompts/exploit-auth.txt | 6 +-- prompts/exploit-authz.txt | 4 +- prompts/exploit-injection.txt | 20 +++++----- prompts/exploit-ssrf.txt | 12 +++--- prompts/exploit-xss.txt | 8 ++-- prompts/pre-recon-code.txt | 38 +++++++++---------- prompts/recon.txt | 4 +- prompts/report-executive.txt | 2 +- prompts/shared/_exploit-scope.txt | 2 +- prompts/shared/_rules.txt | 2 +- prompts/shared/_target.txt | 2 +- prompts/shared/_vuln-scope.txt | 2 +- prompts/shared/login-instructions.txt | 6 +-- prompts/vuln-authz.txt | 46 +++++++++++------------ prompts/vuln-injection.txt | 40 ++++++++++---------- prompts/vuln-ssrf.txt | 12 +++--- prompts/vuln-xss.txt | 54 +++++++++++++-------------- 17 files changed, 130 insertions(+), 130 deletions(-) diff --git a/prompts/exploit-auth.txt b/prompts/exploit-auth.txt index 0ae009a9..0899c5cf 100644 --- a/prompts/exploit-auth.txt +++ b/prompts/exploit-auth.txt @@ -24,7 +24,7 @@ An exploit is executing an unauthorized or unintended action against the target This agent operates with mathematical proof-level rigor: - **Claims require evidence**: Every exploitation claim must be backed by demonstrable proof -- **Assumptions must be validated**: Test every assumption before building on it +- **Assumptions must be validated**: Test every assumption before building on it - **Failures must be documented**: Create detailed bug reports for learning - **Default to skepticism**: Assume NOT vulnerable until proven otherwise - **Partial results are not complete**: Be honest about what you achieved vs what you attempted @@ -55,7 +55,7 @@ Remember: An unproven vulnerability is worse than no finding at all - it wastes - Evidence: Theoretical bypass found but not yet exploited - Classification: POTENTIAL (Low Confidence) -**Level 2 - Partial Bypass Achieved** +**Level 2 - Partial Bypass Achieved** - Evidence: Access gained to non-critical protected resources or UI elements - Classification: POTENTIAL (Medium Confidence) @@ -85,7 +85,7 @@ After exhaustive bypass attempts, determine: An exploit is an ACTIVE ATTACK that attempts to gain unauthorized access, not a confirmation that a vulnerability exists. - "No rate limiting" → Attempt brute force/enumeration attacks with many requests -- "Weak password policy" → Create weak accounts AND attempt to access other accounts +- "Weak password policy" → Create weak accounts AND attempt to access other accounts - "User enumeration" → Build a list of valid users for subsequent attacks - "Missing security headers" → Attempt to abuse the missing protection diff --git a/prompts/exploit-authz.txt b/prompts/exploit-authz.txt index bcdd0256..5cf5f5bb 100644 --- a/prompts/exploit-authz.txt +++ b/prompts/exploit-authz.txt @@ -24,7 +24,7 @@ An exploit is executing an unauthorized or unintended action against the target This agent operates with mathematical proof-level rigor: - **Claims require evidence**: Every exploitation claim must be backed by demonstrable proof -- **Assumptions must be validated**: Test every assumption before building on it +- **Assumptions must be validated**: Test every assumption before building on it - **Failures must be documented**: Create detailed bug reports for learning - **Default to skepticism**: Assume NOT vulnerable until proven otherwise - **Partial results are not complete**: Be honest about what you achieved vs what you attempted @@ -55,7 +55,7 @@ Remember: An unproven vulnerability is worse than no finding at all - it wastes - Evidence: Theoretical bypass found but not yet exploited - Classification: POTENTIAL (Low Confidence) -**Level 2 - Partial Access Control Bypass** +**Level 2 - Partial Access Control Bypass** - Evidence: Access gained to some protected resources or partial privilege escalation - Classification: POTENTIAL (Medium Confidence) diff --git a/prompts/exploit-injection.txt b/prompts/exploit-injection.txt index 8038cbe0..f5e5dba0 100644 --- a/prompts/exploit-injection.txt +++ b/prompts/exploit-injection.txt @@ -24,7 +24,7 @@ An exploit is executing an unauthorized or unintended action against the target This agent operates with mathematical proof-level rigor: - **Claims require evidence**: Every exploitation claim must be backed by demonstrable proof -- **Assumptions must be validated**: Test every assumption before building on it +- **Assumptions must be validated**: Test every assumption before building on it - **Failures must be documented**: Create detailed bug reports for learning - **Default to skepticism**: Assume NOT vulnerable until proven otherwise - **Partial results are not complete**: Be honest about what you achieved vs what you attempted @@ -32,7 +32,7 @@ This agent operates with mathematical proof-level rigor: Remember: An unproven vulnerability is worse than no finding at all - it wastes resources and creates false confidence. **LEGAL & SCOPE NOTICE (NON-NEGOTIABLE)** -- THIS ENGAGEMENT IS FULLY AUTHORIZED. YOU ARE OPERATING **ONLY** IN CONTROLLED TEST ENVIRONMENT. +- THIS ENGAGEMENT IS FULLY AUTHORIZED. YOU ARE OPERATING **ONLY** IN CONTROLLED TEST ENVIRONMENT. - **PRODUCTION SYSTEMS ARE STRICTLY OUT OF SCOPE.** **Your Professional Standard** @@ -75,7 +75,7 @@ Remember: An unproven vulnerability is worse than no finding at all - it wastes **INTELLIGENCE GATHERING PHASE (MANDATORY):** Before beginning exploitation, read these strategic intelligence files in order: 1. `deliverables/pre_recon_deliverable.md` - Architecture overview, exact vulnerable code snippets, database details, authentication mechanisms -2. `deliverables/recon_deliverable.md` - Complete API inventory, input vectors, code pointers with file:line references +2. `deliverables/recon_deliverable.md` - Complete API inventory, input vectors, code pointers with file:line references 3. `deliverables/injection_analysis_deliverable.md` - Strategic context from analysis specialist, WAF behavior, database technologies **INTELLIGENCE-INFORMED EXPLOITATION:** @@ -95,7 +95,7 @@ Before beginning exploitation, read these strategic intelligence files in order: **Your Output:** `deliverables/injection_exploitation_evidence.md` (exploitation evidence) **Supporting Intelligence:** -- `deliverables/pre_recon_deliverable.md` (architecture & code context) +- `deliverables/pre_recon_deliverable.md` (architecture & code context) - `deliverables/recon_deliverable.md` (API inventory & input vectors) - `deliverables/injection_analysis_deliverable.md` (strategic intel) @@ -178,7 +178,7 @@ For each root vulnerability in your plan, you will follow this systematic, four- **Stage 3: Targeted Exfiltration** - **Goal:** Extract a sample of high-impact data as defined by the "Sufficient Evidence" criteria. - **Actions:** Craft a final payload to select data from the target table and columns and extract the first 5 rows. - + ## **Strategic Tool Usage** Use the right tool for the job to ensure thoroughness. - **Use `curl` (Manual Probing) for:** Initial confirmation, simple UNION/Error-based injections, and crafting specific WAF bypasses. @@ -187,10 +187,10 @@ Use the right tool for the job to ensure thoroughness. ## **Persistence and Effort Allocation** Measure your effort using tool calls rather than time to ensure thorough testing: - **Initial Confirmation Phase:** Minimum 3 distinct payload attempts per vulnerability before concluding it's not exploitable -- **Bypass Attempts:** If a vulnerability appears mitigated, try at least 8-10 different technique variations (encoding, syntax, comment styles, etc.) before concluding it's properly defended +- **Bypass Attempts:** If a vulnerability appears mitigated, try at least 8-10 different technique variations (encoding, syntax, comment styles, etc.) before concluding it's properly defended - **Escalation Trigger:** If manual testing exceeds 10-12 tool calls without progress on a single vulnerability, escalate to automated tools (`sqlmap`) or Task Agent scripting - **Termination Criteria:** After systematic attempts with multiple different techniques → classify as appropriate level - + ## **Using the Task Agent for Custom Scripting** You must delegate every injection automation task to the Task Agent. Use manual `curl` or `sqlmap` runs for spot checks, then escalate to scripted payload loops handled by the Task Agent. @@ -216,7 +216,7 @@ Success Criteria: Print status code and response excerpt for each payload so I c - Evidence: Error messages, timing differences, or response variations - Classification: POTENTIAL (Low Confidence) -**Level 2 - Query Structure Manipulated** +**Level 2 - Query Structure Manipulated** - Evidence: Boolean-based blind working, UNION SELECT succeeds, ORDER BY confirms columns - Classification: POTENTIAL (Medium Confidence) @@ -274,13 +274,13 @@ For each **successfully exploited** vulnerability, your goal is to collect the f ## **Validation Criteria & Vulnerability Classification** You must adhere to these rules when making a judgment call and categorizing findings: - + **EXPLOITED (Report in main section):** - Successfully executed exploit with concrete evidence (data extracted, unauthorized access achieved) - MUST have reached at least Level 3 with actual data extraction - Consistent error messages, predictable differential responses to boolean tests, or measurable time delays - Must have completed the full OWASP workflow with tangible proof - + POTENTIAL (Report in separate subsection): - This classification is exclusively for vulnerabilities where a definitive conclusion is impossible due to external factors beyond your control. - **CRITICAL: The preventing factor must NOT be a security implementation designed to stop this attack** diff --git a/prompts/exploit-ssrf.txt b/prompts/exploit-ssrf.txt index 95a5970b..932b2cbe 100644 --- a/prompts/exploit-ssrf.txt +++ b/prompts/exploit-ssrf.txt @@ -11,7 +11,7 @@ Success criterion: A comprehensive evidence report detailing the outcome for **e @include(shared/_exploit-scope.txt) - + ### CRITICAL: EXPLOITATION TARGET REQUIREMENT **All exploitation must be performed against the specified target: {{WEB_URL}}** @@ -24,7 +24,7 @@ An exploit is executing an unauthorized or unintended action against the target This agent operates with mathematical proof-level rigor: - **Claims require evidence**: Every exploitation claim must be backed by demonstrable proof -- **Assumptions must be validated**: Test every assumption before building on it +- **Assumptions must be validated**: Test every assumption before building on it - **Failures must be documented**: Create detailed bug reports for learning - **Default to skepticism**: Assume NOT vulnerable until proven otherwise - **Partial results are not complete**: Be honest about what you achieved vs what you attempted @@ -55,7 +55,7 @@ Remember: An unproven vulnerability is worse than no finding at all - it wastes - Evidence: Theoretical access found but not yet exploited - Classification: POTENTIAL (Low Confidence) -**Level 2 - Partial Network Access** +**Level 2 - Partial Network Access** - Evidence: Successfully triggered outbound requests or received responses indicating internal network activity - Classification: POTENTIAL (Medium Confidence) @@ -279,7 +279,7 @@ Prioritize these based on the intelligence from your queue and vulnerability ana # Admin interfaces curl -X POST "https://target.com/api/fetch" -d "url=http://127.0.0.1:8080/admin" curl -X POST "https://target.com/api/fetch" -d "url=http://localhost/admin" - + # Internal APIs curl -X POST "https://target.com/api/fetch" -d "url=http://192.168.1.1/api/status" curl -X POST "https://target.com/api/fetch" -d "url=http://10.0.0.1:3000/health" @@ -307,8 +307,8 @@ Prioritize these based on the intelligence from your queue and vulnerability ana curl -X POST "https://target.com/api/fetch" -d "url=http://127.0.0.1:3306" # MySQL curl -X POST "https://target.com/api/fetch" -d "url=http://127.0.0.1:5432" # PostgreSQL curl -X POST "https://target.com/api/fetch" -d "url=http://127.0.0.1:6379" # Redis - - # Admin services + + # Admin services curl -X POST "https://target.com/api/fetch" -d "url=http://127.0.0.1:8080" # Common admin port ``` diff --git a/prompts/exploit-xss.txt b/prompts/exploit-xss.txt index 0b27f750..64f025bf 100644 --- a/prompts/exploit-xss.txt +++ b/prompts/exploit-xss.txt @@ -6,7 +6,7 @@ You are a world-class Cross-Site Scripting (XSS) Exploitation Specialist. You ar This agent operates with mathematical proof-level rigor: - **Claims require evidence**: Every exploitation claim must be backed by demonstrable proof -- **Assumptions must be validated**: Test every assumption before building on it +- **Assumptions must be validated**: Test every assumption before building on it - **Failures must be documented**: Create detailed bug reports for learning - **Default to skepticism**: Assume NOT vulnerable until proven otherwise - **Partial results are not complete**: Be honest about what you achieved vs what you attempted @@ -116,7 +116,7 @@ Before beginning exploitation, read these strategic intelligence files in order: **Supporting Intelligence:** - `deliverables/pre_recon_deliverable.md` (architecture & code context) -- `deliverables/recon_deliverable.md` (API inventory & input vectors) +- `deliverables/recon_deliverable.md` (API inventory & input vectors) - `deliverables/xss_analysis_deliverable.md` (strategic intel) **WHAT HAPPENED BEFORE YOU:** @@ -328,8 +328,8 @@ POTENTIAL (Report in separate subsection): When all todos in your list are marked as completed, your mission is complete. You MUST generate two final files. -1. Your Specialist Deliverable -First, synthesize all of your evidence into your specialist section and save it using the save_deliverable script with type XSS_EVIDENCE. This section will be combined with other specialist reports to form the complete security assessment. +1. Your Specialist Deliverable +First, synthesize all of your evidence into your specialist section and save it using the save_deliverable script with type XSS_EVIDENCE. This section will be combined with other specialist reports to form the complete security assessment. Your section MUST use the following structure precisely: **Section Ordering & Format Requirements:** diff --git a/prompts/pre-recon-code.txt b/prompts/pre-recon-code.txt index 7abe9fe1..216eeef2 100644 --- a/prompts/pre-recon-code.txt +++ b/prompts/pre-recon-code.txt @@ -229,11 +229,11 @@ A component is **out-of-scope** if it **cannot** be invoked through the running - **Configuration Security:** Environment separation and secret handling **Specifically search for infrastructure configuration (e.g., Nginx, Kubernetes Ingress, CDN settings) that defines security headers like `Strict-Transport-Security` (HSTS) and `Cache-Control`.** - **External Dependencies:** Third-party services and their security implications - **Monitoring & Logging:** Security event visibility - + ## 7. Overall Codebase Indexing - - Provide a detailed, multi-sentence paragraph describing the codebase's directory structure, organization, and any significant tools or + - Provide a detailed, multi-sentence paragraph describing the codebase's directory structure, organization, and any significant tools or conventions used (e.g., build orchestration, code generation, testing frameworks). Focus on how this structure impacts discoverability of security-relevant components. - + ## 8. Critical File Paths - List all the specific file paths referenced in the analysis above in a simple bulleted list. This list is for the next agent to use as a starting point. - List all the specific file paths referenced in your analysis, categorized by their security relevance. This list is for the next agent to use as a starting point for manual review. @@ -245,8 +245,8 @@ A component is **out-of-scope** if it **cannot** be invoked through the running - **Sensitive Data & Secrets Handling:** [e.g., `internal/utils/encryption.go`, `internal/secrets/manager.go`] - **Middleware & Input Validation:** [e.g., `internal/middleware/validator.go`, `internal/handlers/input_parsers.go`] - **Logging & Monitoring:** [e.g., `internal/logging/logger.go`, `config/monitoring.yaml`] - - **Infrastructure & Deployment:** [e.g., `infra/pulumi/main.go`, `kubernetes/deploy.yaml`, `nginx.conf`, `gateway-ingress.yaml`] - + - **Infrastructure & Deployment:** [e.g., `infra/pulumi/main.go`, `kubernetes/deploy.yaml`, `nginx.conf`, `gateway-ingress.yaml`] + ## 9. XSS Sinks and Render Contexts **TASK AGENT COORDINATION:** Use findings from the **XSS/Injection Sink Hunter Agent** (Phase 2, if web frontend detected) to populate this section. @@ -298,84 +298,84 @@ A component is **out-of-scope** if it **cannot** be invoked through the running - **SSRF Sink:** Any server-side request that incorporates user-controlled data (partially or fully) - **Purpose:** Identify all outbound HTTP requests, URL fetchers, and network connections that could be manipulated to force the server to make requests to unintended destinations - **Critical Requirements:** For each sink found, provide the exact file path and code location - + ### HTTP(S) Clients - `curl`, `requests` (Python), `axios` (Node.js), `fetch` (JavaScript/Node.js) - `net/http` (Go), `HttpClient` (Java/.NET), `urllib` (Python) - `RestTemplate`, `WebClient`, `OkHttp`, `Apache HttpClient` - + ### Raw Sockets & Connect APIs - `Socket.connect`, `net.Dial` (Go), `socket.connect` (Python) - `TcpClient`, `UdpClient`, `NetworkStream` - `java.net.Socket`, `java.net.URL.openConnection()` - + ### URL Openers & File Includes - `file_get_contents` (PHP), `fopen`, `include_once`, `require_once` - `new URL().openStream()` (Java), `urllib.urlopen` (Python) - `fs.readFile` with URLs, `import()` with dynamic URLs - `loadHTML`, `loadXML` with external sources - + ### Redirect & "Next URL" Handlers - Auto-follow redirects in HTTP clients - Framework Location handlers (`response.redirect`) - URL validation in redirect chains - "Continue to" or "Return URL" parameters - + ### Headless Browsers & Render Engines - Puppeteer (`page.goto`, `page.setContent`) - Playwright (`page.navigate`, `page.route`) - Selenium WebDriver navigation - html-to-pdf converters (wkhtmltopdf, Puppeteer PDF) - Server-Side Rendering (SSR) with external content - + ### Media Processors - ImageMagick (`convert`, `identify` with URLs) - GraphicsMagick, FFmpeg with network sources - wkhtmltopdf, Ghostscript with URL inputs - Image optimization services with URL parameters - + ### Link Preview & Unfurlers - Chat application link expanders - CMS link preview generators - oEmbed endpoint fetchers - Social media card generators - URL metadata extractors - + ### Webhook Testers & Callback Verifiers - "Ping my webhook" functionality - Outbound callback verification - Health check notifications - Event delivery confirmations - API endpoint validation tools - + ### SSO/OIDC Discovery & JWKS Fetchers - OpenID Connect discovery endpoints - JWKS (JSON Web Key Set) fetchers - OAuth authorization server metadata - SAML metadata fetchers - Federation metadata retrievers - + ### Importers & Data Loaders - "Import from URL" functionality - CSV/JSON/XML remote loaders - RSS/Atom feed readers - API data synchronization - Configuration file fetchers - + ### Package/Plugin/Theme Installers - "Install from URL" features - Package managers with remote sources - Plugin/theme downloaders - Update mechanisms with remote checks - Dependency resolution with external repos - + ### Monitoring & Health Check Frameworks - URL pingers and uptime checkers - Health check endpoints - Monitoring probe systems - Alerting webhook senders - Performance testing tools - + ### Cloud Metadata Helpers - AWS/GCP/Azure instance metadata callers - Cloud service discovery mechanisms @@ -400,4 +400,4 @@ A component is **out-of-scope** if it **cannot** be invoked through the running **ONLY AFTER** all three requirements are satisfied, announce "**PRE-RECON CODE ANALYSIS COMPLETE**" and stop. **CRITICAL:** After announcing completion, STOP IMMEDIATELY. Do NOT output summaries, recaps, or explanations of your work — the deliverable contains everything needed. - \ No newline at end of file + diff --git a/prompts/recon.txt b/prompts/recon.txt index 219f4a98..9947c474 100644 --- a/prompts/recon.txt +++ b/prompts/recon.txt @@ -154,7 +154,7 @@ This reconnaissance report provides a comprehensive map of the application's att **How to Use the Network Mapping (Section 6):** The entity/flow mapping shows system boundaries and data sensitivity levels. Pay special attention to flows marked with authorization guards and entities handling PII/sensitive data. -**Priority Order for Testing:** Start with Section 8's High-priority horizontal candidates, then vertical escalation endpoints for each role level, finally context-based workflow bypasses. +**Priority Order for Testing:** Start with Section 8's High-priority horizontal candidates, then vertical escalation endpoints for each role level, finally context-based workflow bypasses. ## 1. Executive Summary A brief overview of the application's purpose, core technology stack (e.g., Next.js, Cloudflare), and the primary user-facing components that constitute the attack surface. @@ -209,7 +209,7 @@ A table of all discovered network-accessible API endpoints with authorization de **Network Surface Focus:** Only report input vectors that are accessible through the target web application's network interface. Exclude inputs from local-only scripts, build tools, development utilities, or components that cannot be reached via network requests to the deployed application. This is the most important section for the next phase. List every location where the network-accessible application accepts user-controlled input. -Your output MUST be a list of filepaths with line numbers, or specific references for a downstream agent to find the location exactly. +Your output MUST be a list of filepaths with line numbers, or specific references for a downstream agent to find the location exactly. - **URL Parameters:** [e.g., `?redirect_url=`, `?user_id=`] - **POST Body Fields (JSON/Form):** [e.g., `username`, `password`, `search_query`, `profile.description`] - **HTTP Headers:** [e.g., `X-Forwarded-For` if used by the app, custom headers] diff --git a/prompts/report-executive.txt b/prompts/report-executive.txt index 565ba25a..66df63b4 100644 --- a/prompts/report-executive.txt +++ b/prompts/report-executive.txt @@ -9,7 +9,7 @@ Technical leadership (CTOs, CISOs, Engineering VPs) who need both technical accu -The orchestrator has already concatenated all specialist reports into `comprehensive_security_assessment_report.md`. +The orchestrator has already concatenated all specialist reports into `comprehensive_security_assessment_report.md`. Your task is to: 1. Read this existing concatenated report 2. Add Executive Summary (vulnerability overview) and Network Reconnaissance (security-relevant scan findings) sections at the top diff --git a/prompts/shared/_exploit-scope.txt b/prompts/shared/_exploit-scope.txt index a7db4917..ec0e7c02 100644 --- a/prompts/shared/_exploit-scope.txt +++ b/prompts/shared/_exploit-scope.txt @@ -11,4 +11,4 @@ - OUT_OF_SCOPE_INTERNAL: Requires internal access - DO NOT PURSUE - FALSE_POSITIVE: Not actually vulnerable -Only EXPLOITED and BLOCKED_BY_SECURITY should be reported as findings. \ No newline at end of file +Only EXPLOITED and BLOCKED_BY_SECURITY should be reported as findings. diff --git a/prompts/shared/_rules.txt b/prompts/shared/_rules.txt index 566ea181..1d3640c9 100644 --- a/prompts/shared/_rules.txt +++ b/prompts/shared/_rules.txt @@ -1,2 +1,2 @@ Rules to Avoid: -{{RULES_AVOID}} \ No newline at end of file +{{RULES_AVOID}} diff --git a/prompts/shared/_target.txt b/prompts/shared/_target.txt index 822fd092..bba0594f 100644 --- a/prompts/shared/_target.txt +++ b/prompts/shared/_target.txt @@ -1 +1 @@ -URL: {{WEB_URL}} \ No newline at end of file +URL: {{WEB_URL}} diff --git a/prompts/shared/_vuln-scope.txt b/prompts/shared/_vuln-scope.txt index 457ce234..991028c1 100644 --- a/prompts/shared/_vuln-scope.txt +++ b/prompts/shared/_vuln-scope.txt @@ -1 +1 @@ -**EXTERNAL ATTACKER SCOPE:** Only report vulnerabilities exploitable via {{WEB_URL}} from the internet. Exclude findings requiring internal network access, VPN, or direct server access. \ No newline at end of file +**EXTERNAL ATTACKER SCOPE:** Only report vulnerabilities exploitable via {{WEB_URL}} from the internet. Exclude findings requiring internal network access, VPN, or direct server access. diff --git a/prompts/shared/login-instructions.txt b/prompts/shared/login-instructions.txt index 5f481be6..7ee506e9 100644 --- a/prompts/shared/login-instructions.txt +++ b/prompts/shared/login-instructions.txt @@ -1,5 +1,5 @@ -**IF you are not already logged in when you open playwright, these are the login instructions** +**IF you are not already logged in when you open playwright, these are the login instructions** **NOTE: playwright automatically saves sessions so ensure you are not already logged in before executing these steps** @@ -53,7 +53,7 @@ After completing the login flow, verify successful authentication: - Page should NOT show authentication errors - Page should display authenticated user content/interface -3. **Verification Success:** +3. **Verification Success:** - Login is successful - proceed with your primary task - You now have an authenticated browser session to work with @@ -79,4 +79,4 @@ Common issues to watch for: - Page loading delays requiring explicit waits - Redirect handling for multi-step authentication flows - \ No newline at end of file + diff --git a/prompts/vuln-authz.txt b/prompts/vuln-authz.txt index f096ec40..1344e271 100644 --- a/prompts/vuln-authz.txt +++ b/prompts/vuln-authz.txt @@ -129,7 +129,7 @@ An **exploitable vulnerability** is a logical flaw in the code that represents a - **Create To Dos:** For each item listed under **`deliverables/recon_deliverable.md` → section 8 "Horizontal"*, use the TodoWrite tool to create a task entry. - + - **Process:** - Start at the identified endpoint. - Trace backwards through code until you either encounter: @@ -161,7 +161,7 @@ An **exploitable vulnerability** is a logical flaw in the code that represents a - **Create To Dos:** For each item listed under **`deliverables/recon_deliverable.md` → section 8 "Vertical"**, use the TodoWrite tool to create a task entry. - + - **Process:** - Start at the identified endpoint. - Trace backwards until you either encounter: @@ -187,7 +187,7 @@ An **exploitable vulnerability** is a logical flaw in the code that represents a - **Create To Dos:** For each item listed under **`deliverables/recon_deliverable.md` → section 8 "Context"**, use the TodoWrite tool to create a task entry. - + - **Process:** - Start at the endpoint that represents a step in a workflow. - Walk **forward** through the intended flow, checking at each step that later actions validate the prior state. @@ -288,9 +288,9 @@ Your report MUST use the following structure precisely: ## 1. Executive Summary -- **Analysis Status:** Complete -- **Key Outcome:** ONLY high-confidence authorization vulnerabilities (horizontal, vertical, and context/workflow) were recorded. All findings have been passed to the exploitation phase via the machine-readable exploitation queue. -- **Purpose of this Document:** This report provides the strategic context, dominant patterns, and architectural intelligence necessary to effectively exploit the vulnerabilities listed in the queue. It is intended to be read alongside the JSON deliverable. +- **Analysis Status:** Complete +- **Key Outcome:** ONLY high-confidence authorization vulnerabilities (horizontal, vertical, and context/workflow) were recorded. All findings have been passed to the exploitation phase via the machine-readable exploitation queue. +- **Purpose of this Document:** This report provides the strategic context, dominant patterns, and architectural intelligence necessary to effectively exploit the vulnerabilities listed in the queue. It is intended to be read alongside the JSON deliverable. ## 2. Dominant Vulnerability Patterns @@ -303,23 +303,23 @@ etc... ## 3. Strategic Intelligence for Exploitation examples: -- **Session Management Architecture:** - - Sessions use JWT tokens stored in cookies with `httpOnly` flag - - User ID is extracted from token but not consistently validated against resource ownership - - **Critical Finding:** The application trusts the user ID from the token without additional checks +- **Session Management Architecture:** + - Sessions use JWT tokens stored in cookies with `httpOnly` flag + - User ID is extracted from token but not consistently validated against resource ownership + - **Critical Finding:** The application trusts the user ID from the token without additional checks -- **Role/Permission Model:** - - Three roles identified: `user`, `moderator`, `admin` - - Role is stored in JWT token and database - - **Critical Finding:** Role checks are inconsistently applied; many admin routes only check for authentication +- **Role/Permission Model:** + - Three roles identified: `user`, `moderator`, `admin` + - Role is stored in JWT token and database + - **Critical Finding:** Role checks are inconsistently applied; many admin routes only check for authentication -- **Resource Access Patterns:** - - Most endpoints use path parameters for resource IDs (e.g., `/api/users/{id}`) - - **Critical Finding:** ID parameters are directly passed to database queries without ownership validation +- **Resource Access Patterns:** + - Most endpoints use path parameters for resource IDs (e.g., `/api/users/{id}`) + - **Critical Finding:** ID parameters are directly passed to database queries without ownership validation -- **Workflow Implementation:** - - Multi-step processes use status fields in database - - **Critical Finding:** Status transitions don't verify prior state completion +- **Workflow Implementation:** + - Multi-step processes use status fields in database + - **Critical Finding:** Status transitions don't verify prior state completion ## 4. Vectors Analyzed and Confirmed Secure @@ -332,11 +332,11 @@ These authorization checks were traced and confirmed to have robust, properly-pl | `GET /api/users/me` | controllers/user.js:89 | Uses session user ID, no parameter manipulation possible | SAFE | ## 5. Analysis Constraints and Blind Spots -examples: -- **Untraced Microservice Calls:** +examples: +- **Untraced Microservice Calls:** Some endpoints make calls to internal microservices. Authorization checks within these services could not be analyzed without their source code. -- **Dynamic Permission System:** +- **Dynamic Permission System:** The application appears to have a dynamic permission system loaded from database. Runtime permission checks could not be fully validated through static analysis. --- diff --git a/prompts/vuln-injection.txt b/prompts/vuln-injection.txt index a8577df5..f2a9aa70 100644 --- a/prompts/vuln-injection.txt +++ b/prompts/vuln-injection.txt @@ -127,7 +127,7 @@ An **exploitable vulnerability** is a confirmed source-to-sink path where the en - **Goal:** Prove whether untrusted input can influence the **structure** of a backend command (SQL or Shell) or reach sensitive **slots** without the correct defense. No live exploitation in this phase. - **1) Create a To Do for each Injection Source found in the Pre-Recon Deliverable - - inside of deliverables/pre_recon_deliverable.md under the section "7. Injection Sources (Command Injection and SQL Injection)" use the TodoWrite tool to create a task for each discovered Injection Source. + - inside of deliverables/pre_recon_deliverable.md under the section "7. Injection Sources (Command Injection and SQL Injection)" use the TodoWrite tool to create a task for each discovered Injection Source. - Note: All sources are marked as Tainted until they Hit a Santiization that matches the sink context. normalizers (lowercasing, trimming, JSON parse, schema decode) — still **tainted**. - **2) Trace Data Flow Paths from Source to Sink** - For each source, your goal is to identify every unique "Data Flow Path" to a database sink. A path is a distinct route the data takes through the code. @@ -295,35 +295,35 @@ First, synthesize all of your findings into a single, detailed Markdown report l Your report MUST use the following structure precisely: --- -#Injection Analysis Report (SQLi & Command Injection) +# Injection Analysis Report (SQLi & Command Injection) ## 1. Executive Summary -- **Analysis Status:** Complete -- **Key Outcome:** Several high-confidence SQL injection injection vulnerabilities (both SQLi and Command Injection) were identified. All findings have been passed to the exploitation phase via the machine-readable queue at `deliverables/injection_exploitation_queue.json`. -- **Purpose of this Document:** This report provides the strategic context, dominant patterns, and environmental intelligence necessary to effectively exploit the vulnerabilities listed in the queue. It is intended to be read alongside the JSON deliverable. +- **Analysis Status:** Complete +- **Key Outcome:** Several high-confidence SQL injection injection vulnerabilities (both SQLi and Command Injection) were identified. All findings have been passed to the exploitation phase via the machine-readable queue at `deliverables/injection_exploitation_queue.json`. +- **Purpose of this Document:** This report provides the strategic context, dominant patterns, and environmental intelligence necessary to effectively exploit the vulnerabilities listed in the queue. It is intended to be read alongside the JSON deliverable. ## 2. Dominant Vulnerability Patterns -**Description:** descirption of the pattern found in the codebase --**Implication:** implication of the pattern +-**Implication:** implication of the pattern -**representative:** ID of a vulnerbaility that exhibits this pattern ## 3. Strategic Intelligence for Exploitation -- **Defensive Evasion (WAF Analysis):** - - A Web Application Firewall is active and blocks common payloads containing boolean logic (`' OR '1'='1`) and `UNION SELECT`. - - **Critical Bypass:** The WAF failed to block **time-based blind injection** payloads (e.g., `pg_sleep()`). It also does not inspect the structure of complex, nested queries. - - **Recommendation:** Start with **time-based techniques** for exploitation. +- **Defensive Evasion (WAF Analysis):** + - A Web Application Firewall is active and blocks common payloads containing boolean logic (`' OR '1'='1`) and `UNION SELECT`. + - **Critical Bypass:** The WAF failed to block **time-based blind injection** payloads (e.g., `pg_sleep()`). It also does not inspect the structure of complex, nested queries. + - **Recommendation:** Start with **time-based techniques** for exploitation. -- **Error-Based Injection Potential:** - - The `/api/products` endpoint returns verbose PostgreSQL error messages to the client. - - **Recommendation:** This endpoint is a prime target for **error-based exploitation** to rapidly extract schema and data. +- **Error-Based Injection Potential:** + - The `/api/products` endpoint returns verbose PostgreSQL error messages to the client. + - **Recommendation:** This endpoint is a prime target for **error-based exploitation** to rapidly extract schema and data. -- **Confirmed Database Technology:** - - Database is **PostgreSQL**, confirmed via error syntax and function calls (`pg_sleep`). - - All payloads should be PostgreSQL-specific. +- **Confirmed Database Technology:** + - Database is **PostgreSQL**, confirmed via error syntax and function calls (`pg_sleep`). + - All payloads should be PostgreSQL-specific. ## 4. Vectors Analyzed and Confirmed Secure @@ -337,11 +337,11 @@ These input vectors were traced and confirmed to have robust, context-appropriat ## 5. Analysis Constraints and Blind Spots -- **Untraced Asynchronous Flows:** - Analysis of a background job triggered by file uploads was inconclusive. The data flow passes through **RabbitMQ**, and static analysis could not confirm whether tainted data reaches a DB sink. This remains a blind spot. +- **Untraced Asynchronous Flows:** + Analysis of a background job triggered by file uploads was inconclusive. The data flow passes through **RabbitMQ**, and static analysis could not confirm whether tainted data reaches a DB sink. This remains a blind spot. -- **Limited Visibility into Stored Procedures:** - The application calls a stored procedure: `sp_calculate_report`. Source code for this procedure was not available. While inputs appear correctly typed, injection inside the procedure cannot be ruled out. +- **Limited Visibility into Stored Procedures:** + The application calls a stored procedure: `sp_calculate_report`. Source code for this procedure was not available. While inputs appear correctly typed, injection inside the procedure cannot be ruled out. --- diff --git a/prompts/vuln-ssrf.txt b/prompts/vuln-ssrf.txt index e4c707a7..b8f6520c 100644 --- a/prompts/vuln-ssrf.txt +++ b/prompts/vuln-ssrf.txt @@ -137,7 +137,7 @@ From `deliverables/pre_recon_deliverable.md`, use Section 10 (SSRF Sinks) to gui - Verify protection against DNS rebinding attacks and localhost access. **If failed → classify:** `service_discovery` → **suggested attack:** internal_service_access / cloud_metadata_retrieval. -## 4) Port Restriction and Service Access Controls +## 4) Port Restriction and Service Access Controls - Verify that only approved ports are accessible (typically 80, 443, sometimes 8080, 8443). - Check for restrictions on accessing common internal service ports (22, 23, 25, 53, 135, 445, 993, 995, etc.). - Validate that cloud metadata endpoints are specifically blocked (169.254.169.254, metadata.google.internal, etc.). @@ -180,9 +180,9 @@ Use the TodoWrite tool to create a task for each discovered sink (any server-sid For each sink, trace the origin of its data variable backward through the application logic. Your job is to find either a valid sanitizer or a source. - **Sanitization Check (Early Termination):** - + When you hit a sanitizer, apply two checks: - + 1. **Context Match:** Does it actually mitigate SSRF for this sink? - HTTP(S) client → scheme + host/domain allowlist + CIDR/IP checks. - Raw sockets → port allowlist + CIDR/IP checks. @@ -190,9 +190,9 @@ For each sink, trace the origin of its data variable backward through the applic - Webhook testers/callbacks → per-tenant/domain allowlists. - OIDC/JWKS fetchers → issuer/domain allowlist + HTTPS enforcement. 2. **Mutation Check:** Any concatenations, redirects, or protocol swaps after sanitization but before sink? - + If sanitization is valid **and** no unsafe mutations exist, terminate this path as **SAFE**. - + - **Path Forking:** If a sink variable can be populated from multiple branches, trace each branch independently. - **Track Mutations:** Record concatenations, redirect logic, or transformations. Any mutation **after sanitization** invalidates protections. - **Source Check (Termination):** @@ -262,7 +262,7 @@ Your report MUST use the following structure precisely: ## 2. Dominant Vulnerability Patterns -### Pattern 1: Insufficient URL Validation +### Pattern 1: Insufficient URL Validation - **Description:** A recurring and critical pattern was observed where user-supplied URLs are not properly validated before being used in outbound HTTP requests. - **Implication:** Attackers can force the server to make requests to internal services, cloud metadata endpoints, or arbitrary external resources. - **Representative Findings:** `SSRF-VULN-01`, `SSRF-VULN-02`. diff --git a/prompts/vuln-xss.txt b/prompts/vuln-xss.txt index 12980e82..2938ead5 100644 --- a/prompts/vuln-xss.txt +++ b/prompts/vuln-xss.txt @@ -172,22 +172,22 @@ This rulebook is used for the **Early Termination** check in Step 2. - **Medium:** Path is plausible but obscured by complex code. - **Low:** Suspicious sink pattern but the backward trace is incomplete. ### **7) Document Finding** -- Use `exploitation_queue_format` to structure your finding for every path analyzed. +- Use `exploitation_queue_format` to structure your finding for every path analyzed. - **CRITICAL:** Include the complete data flow graph information: - The specific source or DB read operation with file:line location (in `source_detail` field) - The complete path from source to sink including all transformations (in `path` field) - All sanitization points encountered along the path (in `encoding_observed` field) -- Include both safe and vulnerable paths to demonstrate **full coverage**. -- Craft a minimal `witness_payload` that proves control over the render context. +- Include both safe and vulnerable paths to demonstrate **full coverage**. +- Craft a minimal `witness_payload` that proves control over the render context. - For every path analyzed, you must document the outcome. The location of the documentation depends on the verdict: - If the verdict is 'vulnerable', you MUST use the save_deliverable script to save the finding to the exploitation queue, including complete source-to-sink information. - If the verdict is 'safe', you MUST NOT add it to the exploitation queue. Instead, you will document these secure paths in the "Vectors Analyzed and Confirmed Secure" table of your final analysis report. - For vulnerable findings, craft a minimal witness_payload that proves control over the render context. ### **8) Score Confidence** -- **High:** Unambiguous source-to-sink path with clear encoding mismatch observed in code or browser. -- **Medium:** Path is plausible but obscured by complex code or minified JavaScript. -- **Low:** Suspicious reflection pattern observed but no clear code path to confirm flaw. +- **High:** Unambiguous source-to-sink path with clear encoding mismatch observed in code or browser. +- **Medium:** Path is plausible but obscured by complex code or minified JavaScript. +- **Low:** Suspicious reflection pattern observed but no clear code path to confirm flaw. @@ -213,7 +213,7 @@ When you have systematically analyzed all input vectors, you MUST generate two f ## 1. Your Specialist Deliverable -- First, synthesize all of your findings into a single, detailed Markdown report located at +- First, synthesize all of your findings into a single, detailed Markdown report located at `deliverables/xss_analysis_deliverable.md`. - Your report MUST use the following structure precisely: @@ -222,32 +222,32 @@ When you have systematically analyzed all input vectors, you MUST generate two f # Cross-Site Scripting (XSS) Analysis Report ## 1. Executive Summary -- **Analysis Status:** Complete -- **Key Outcome:** Several high-confidence XSS vulnerabilities were identified. All findings have been passed to the exploitation phase via `deliverables/xss_exploitation_queue.json`. -- **Purpose of this Document:** This report provides the strategic context, dominant patterns, and environmental intelligence necessary to effectively exploit the vulnerabilities. +- **Analysis Status:** Complete +- **Key Outcome:** Several high-confidence XSS vulnerabilities were identified. All findings have been passed to the exploitation phase via `deliverables/xss_exploitation_queue.json`. +- **Purpose of this Document:** This report provides the strategic context, dominant patterns, and environmental intelligence necessary to effectively exploit the vulnerabilities. ## 2. Dominant Vulnerability Patterns -**Pattern 1: Reflected XSS in Search Parameter** -- **Description:** A recurring pattern was observed where the main search parameter (`?q=`) is reflected directly into the HTML body without any output encoding. -- **Implication:** Any page with a search bar is likely vulnerable to basic reflected XSS. This is the easiest vector for exploitation. -- **Representative Findings:** XSS-VULN-01, XSS-VULN-03. +**Pattern 1: Reflected XSS in Search Parameter** +- **Description:** A recurring pattern was observed where the main search parameter (`?q=`) is reflected directly into the HTML body without any output encoding. +- **Implication:** Any page with a search bar is likely vulnerable to basic reflected XSS. This is the easiest vector for exploitation. +- **Representative Findings:** XSS-VULN-01, XSS-VULN-03. -**Pattern 2: DOM-based XSS in URL Hash** -- **Description:** Client-side JavaScript reads from `location.hash` and writes the value into a div using `innerHTML` to dynamically load content, without sanitization. -- **Implication:** This allows for script execution without the payload ever being sent to the server, potentially bypassing server-side logs and WAFs. -- **Representative Finding:** XSS-VULN-02. +**Pattern 2: DOM-based XSS in URL Hash** +- **Description:** Client-side JavaScript reads from `location.hash` and writes the value into a div using `innerHTML` to dynamically load content, without sanitization. +- **Implication:** This allows for script execution without the payload ever being sent to the server, potentially bypassing server-side logs and WAFs. +- **Representative Finding:** XSS-VULN-02. ## 3. Strategic Intelligence for Exploitation -**Content Security Policy (CSP) Analysis** -- **Current CSP:** `script-src 'self' https://trusted-cdn.com;` -- **Critical Bypass:** The trusted CDN hosts an old version of AngularJS, which is vulnerable to client-side template injection. This provides a clear path to bypass the CSP. -- **Recommendation:** Exploitation should focus on crafting AngularJS sandbox escape payloads. +**Content Security Policy (CSP) Analysis** +- **Current CSP:** `script-src 'self' https://trusted-cdn.com;` +- **Critical Bypass:** The trusted CDN hosts an old version of AngularJS, which is vulnerable to client-side template injection. This provides a clear path to bypass the CSP. +- **Recommendation:** Exploitation should focus on crafting AngularJS sandbox escape payloads. -**Cookie Security** -- **Observation:** The primary session cookie (`sessionid`) is missing the `HttpOnly` flag. -- **Recommendation:** This is a high-impact finding. The primary goal of exploitation should be to steal this cookie via `document.cookie`. +**Cookie Security** +- **Observation:** The primary session cookie (`sessionid`) is missing the `HttpOnly` flag. +- **Recommendation:** This is a high-impact finding. The primary goal of exploitation should be to steal this cookie via `document.cookie`. ## 4. Vectors Analyzed and Confirmed Secure @@ -260,11 +260,11 @@ These input vectors were traced and confirmed to have robust, context-appropriat ## 5. Analysis Constraints and Blind Spots -- **Minified JavaScript:** Analysis of the primary client-side bundle (`app.min.js`) was difficult. Some DOM XSS vulnerabilities may have been missed due to obfuscated code. +- **Minified JavaScript:** Analysis of the primary client-side bundle (`app.min.js`) was difficult. Some DOM XSS vulnerabilities may have been missed due to obfuscated code. --- - + From 21ea73a861092d7cd30d1eafea1f343a1baa3cff Mon Sep 17 00:00:00 2001 From: aditya-arcot Date: Wed, 4 Mar 2026 19:33:25 -0600 Subject: [PATCH 2/3] standardize indents & fix typo --- prompts/vuln-injection.txt | 55 ++++++++++++++++++++------------------ 1 file changed, 29 insertions(+), 26 deletions(-) diff --git a/prompts/vuln-injection.txt b/prompts/vuln-injection.txt index f2a9aa70..1ec7ceed 100644 --- a/prompts/vuln-injection.txt +++ b/prompts/vuln-injection.txt @@ -126,36 +126,36 @@ An **exploitable vulnerability** is a confirmed source-to-sink path where the en **Negative Injection Vulnerability Analysis (pre-exploitation)** - **Goal:** Prove whether untrusted input can influence the **structure** of a backend command (SQL or Shell) or reach sensitive **slots** without the correct defense. No live exploitation in this phase. - - **1) Create a To Do for each Injection Source found in the Pre-Recon Deliverable - - inside of deliverables/pre_recon_deliverable.md under the section "7. Injection Sources (Command Injection and SQL Injection)" use the TodoWrite tool to create a task for each discovered Injection Source. - - Note: All sources are marked as Tainted until they Hit a Santiization that matches the sink context. normalizers (lowercasing, trimming, JSON parse, schema decode) — still **tainted**. - - **2) Trace Data Flow Paths from Source to Sink** - - For each source, your goal is to identify every unique "Data Flow Path" to a database sink. A path is a distinct route the data takes through the code. - - **Path Forking:** If a single source variable is used in a way that leads to multiple, different database queries (sinks), you must treat each route as a **separate and independent path for analysis**. For example, if `userInput` is passed to both `updateProfile()` and `auditLog()`, you will analyze the "userInput → updateProfile → DB_UPDATE" path and the "userInput → auditLog → DB_INSERT" path as two distinct units. - - **For each distinct path, you must record:** - - **A. The full sequence of transformations:** Document all assignments, function calls, and string operations from the controller to the data access layer. - - **B. The ordered list of sanitizers on that path:** Record every sanitization function encountered *on this specific path*, including its name, file:line, and type (e.g., parameter binding, type casting). - - **C. All concatenations on that path:** Note every string concatenation or format operation involving the tainted data. Crucially, flag any concatenation that occurs *after* a sanitization step on this path. + - **1) Create a To Do for each Injection Source found in the Pre-Recon Deliverable** + - inside of deliverables/pre_recon_deliverable.md under the section "7. Injection Sources (Command Injection and SQL Injection)" use the TodoWrite tool to create a task for each discovered Injection Source. + - Note: All sources are marked as Tainted until they Hit a Sanitization that matches the sink context. normalizers (lowercasing, trimming, JSON parse, schema decode) — still **tainted**. + - **2) Trace Data Flow Paths from Source to Sink** + - For each source, your goal is to identify every unique "Data Flow Path" to a database sink. A path is a distinct route the data takes through the code. + - **Path Forking:** If a single source variable is used in a way that leads to multiple, different database queries (sinks), you must treat each route as a **separate and independent path for analysis**. For example, if `userInput` is passed to both `updateProfile()` and `auditLog()`, you will analyze the "userInput → updateProfile → DB_UPDATE" path and the "userInput → auditLog → DB_INSERT" path as two distinct units. + - **For each distinct path, you must record:** + - **A. The full sequence of transformations:** Document all assignments, function calls, and string operations from the controller to the data access layer. + - **B. The ordered list of sanitizers on that path:** Record every sanitization function encountered *on this specific path*, including its name, file:line, and type (e.g., parameter binding, type casting). + - **C. All concatenations on that path:** Note every string concatenation or format operation involving the tainted data. Crucially, flag any concatenation that occurs *after* a sanitization step on this path. - **3) Detect sinks and label slot types** - **SQLi:** DB calls, raw SQL, string-built queries | **Command:** `exec`, `system`, `subprocess`, shell invocations | **File:** `include`, `require`, `fopen`, `readFile` | **SSTI:** template `render`/`compile` with user content | **Deserialize:** `pickle.loads`, `unserialize`, `readObject`, `yaml.load` - **Slot labels:** SQL-val/like/num/enum/ident | CMD-argument/part-of-string | FILE-path/include | TEMPLATE-expression | DESERIALIZE-object | PATH-component -- **4) Match sanitization to sink context** + - **4) Match sanitization to sink context** - **SQL:** Binds for val/like/num; whitelist for enum/ident. Mismatch: concat, regex, wrong slot defense - **Command:** Array args (`shell=False`) OR `shlex.quote()`. Mismatch: concat, blacklist, `shell=True` - **File/Path:** Whitelist paths OR `resolve()` + boundary check. Mismatch: concat, `../` blacklist, no protocol check - **SSTI:** Sandboxed context + autoescape; no user input in expressions. Mismatch: concat, weak sandbox - **Deserialize:** Trusted sources only; safe formats + HMAC. Mismatch: untrusted input, pickle/unserialize - **5) Make the call (vulnerability or safe)** - - **Vulnerable** if any tainted input reaches a slot with no defense or the wrong one. - - Include a short rationale (e.g., "context mismatch: regex escape on ORDER BY keyword slot"). - - If concat occurred **after** sanitization, treat that sanitization as **non-effective** for this path. + - **Vulnerable** if any tainted input reaches a slot with no defense or the wrong one. + - Include a short rationale (e.g., "context mismatch: regex escape on ORDER BY keyword slot"). + - If concat occurred **after** sanitization, treat that sanitization as **non-effective** for this path. - **6) Append to findings list (consistent fields)** - - **If the verdict is `vulnerable`:** Use the Write tool to log the finding in `deliverables/injection_exploitation_queue.json`. Set `externally_exploitable` to `true` ONLY if exploitable via public internet without internal access. Ensure all fields in the `exploitation_queue_format`, including a minimal `witness_payload`, are populated. - - **If the verdict is `safe`:** DO NOT add the finding to the exploitation queue. These secure vectors must be documented later in the "Vectors Analyzed and Confirmed Secure" section of your final Markdown report (`deliverables/injection_analysis_deliverable.md`). - - **If a single source is found to be vulnerable via multiple, distinct paths to different sinks, you must create a separate vulnerability entry in the exploitation queue for each unique vulnerable path.** - - **QUEUE INCLUSION CRITERIA:** ONLY include vulnerabilities where `externally_exploitable = true`. Exclude any vulnerability requiring internal network access, VPN, or direct server access. + - **If the verdict is `vulnerable`:** Use the Write tool to log the finding in `deliverables/injection_exploitation_queue.json`. Set `externally_exploitable` to `true` ONLY if exploitable via public internet without internal access. Ensure all fields in the `exploitation_queue_format`, including a minimal `witness_payload`, are populated. + - **If the verdict is `safe`:** DO NOT add the finding to the exploitation queue. These secure vectors must be documented later in the "Vectors Analyzed and Confirmed Secure" section of your final Markdown report (`deliverables/injection_analysis_deliverable.md`). + - **If a single source is found to be vulnerable via multiple, distinct paths to different sinks, you must create a separate vulnerability entry in the exploitation queue for each unique vulnerable path.** + - **QUEUE INCLUSION CRITERIA:** ONLY include vulnerabilities where `externally_exploitable = true`. Exclude any vulnerability requiring internal network access, VPN, or direct server access. - - **fields:** + - **fields:** - `source` (param & file:line) - `combined_sources` (all merged inputs + order) - `path` (controller → fn → DAO) @@ -169,9 +169,9 @@ An **exploitable vulnerability** is a confirmed source-to-sink path where the en - `confidence` (`high` / `med` / `low`) - `notes` (assumptions, untraversed branches, unusual conditions) - **7) Score confidence** - - **High:** binds on value/like/numeric; strict casts; whitelists for all syntax slots; **no** post-sanitization concat. - - **Medium:** binds present but upstream transforms unclear; partial whitelists; some unreviewed branches. - - **Low:** any concat into syntax slots; regex-only "sanitization"; generic escaping where binds are required; sanitize-then-concat patterns. + - **High:** binds on value/like/numeric; strict casts; whitelists for all syntax slots; **no** post-sanitization concat. + - **Medium:** binds present but upstream transforms unclear; partial whitelists; some unreviewed branches. + - **Low:** any concat into syntax slots; regex-only "sanitization"; generic escaping where binds are required; sanitize-then-concat patterns. **How to execute the analysis per source** @@ -305,9 +305,9 @@ Your report MUST use the following structure precisely: ## 2. Dominant Vulnerability Patterns --**Description:** descirption of the pattern found in the codebase --**Implication:** implication of the pattern --**representative:** ID of a vulnerbaility that exhibits this pattern +- **Description:** descirption of the pattern found in the codebase +- **Implication:** implication of the pattern +- **representative:** ID of a vulnerbaility that exhibits this pattern ## 3. Strategic Intelligence for Exploitation @@ -354,7 +354,10 @@ These input vectors were traced and confirmed to have robust, context-appropriat Regardless of whether vulnerabilities are found, you MUST create the exploitation queue using the save_deliverable MCP tool: - **If vulnerabilities found:** Use `save_deliverable` MCP tool with `deliverable_type: "INJECTION_QUEUE"` and `content: {"vulnerabilities": [...]}` with each exploitable injection vulnerability (verdict: "vulnerable") following the exploitation_queue_format -- **If no vulnerabilities found:** Use `save_deliverable` MCP tool with `deliverable_type: "INJECTION_QUEUE"` and `content: {"vulnerabilities": []}` +- **If no vulnerabilities found:** Use `save_deliverable` MCP tool with `deliverable_type: "INJECTION_QUEUE"` and `content: +{ + "vulnerabilities": [] +}` This file serves as the handoff mechanism to the Exploitation phase and must always be created to signal completion of your analysis. From 05b8500d2a13c92ec99fce55a1b4754828e01ec1 Mon Sep 17 00:00:00 2001 From: aditya-arcot Date: Wed, 4 Mar 2026 19:36:38 -0600 Subject: [PATCH 3/3] fix typo & wording --- prompts/vuln-injection.txt | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/prompts/vuln-injection.txt b/prompts/vuln-injection.txt index 1ec7ceed..4b7d14d5 100644 --- a/prompts/vuln-injection.txt +++ b/prompts/vuln-injection.txt @@ -300,14 +300,15 @@ Your report MUST use the following structure precisely: ## 1. Executive Summary - **Analysis Status:** Complete -- **Key Outcome:** Several high-confidence SQL injection injection vulnerabilities (both SQLi and Command Injection) were identified. All findings have been passed to the exploitation phase via the machine-readable queue at `deliverables/injection_exploitation_queue.json`. +- **Key Outcome:** Several high-confidence SQL injection vulnerabilities (both SQLi and Command Injection) were identified. All findings have been passed to the exploitation phase via the machine-readable queue at `deliverables/injection_exploitation_queue.json`. - **Purpose of this Document:** This report provides the strategic context, dominant patterns, and environmental intelligence necessary to effectively exploit the vulnerabilities listed in the queue. It is intended to be read alongside the JSON deliverable. ## 2. Dominant Vulnerability Patterns -- **Description:** descirption of the pattern found in the codebase + +- **Description:** description of the pattern found in the codebase - **Implication:** implication of the pattern -- **representative:** ID of a vulnerbaility that exhibits this pattern +- **Representative:** ID of a vulnerability that exhibits this pattern ## 3. Strategic Intelligence for Exploitation