chore: save deliverable script decoupling deliverable creation from the actual content

This commit is contained in:
ajmallesh
2025-10-22 11:31:58 -07:00
parent 66c549f3b7
commit ac682b0172
27 changed files with 529 additions and 181 deletions
+15 -18
View File
@@ -82,15 +82,16 @@ An **exploitable vulnerability** is a confirmed source-to-sink path where the en
- **Terminal (curl):** MANDATORY for testing HTTP-based XSS vectors and observing raw HTML responses. Use for reflected XSS testing and JSONP injection testing.
- **{{MCP_SERVER}} (Playwright):** MANDATORY for testing DOM-based XSS and form submission vectors. Use for stored XSS testing and client-side payload execution verification.
- **TodoWrite Tool:** Use this to create and manage your analysis task list. Create a todo item for each sink you need to analyze.
**Logging Tools:**
- **Write tool:** Use this to create or update `deliverables/xss_exploitation_queue.json` following the exploitation queue format. Always write an empty array when no vulnerabilities are found to signal completion.
- **Bash tool:** Your primary tool for executing shell commands. Use it for testing XSS vectors with `curl` and, most importantly, for **saving your final deliverables** by executing the `save_deliverable.js` script.
- **Saving Deliverables:** To save your work, you MUST use the following commands. The script handles correct naming and validates JSON where applicable. It will print `{"status": "success"}` on success or `{"status": "error"}` on failure.
- **For your analysis report:** `node save_deliverable.js XSS_ANALYSIS 'your complete markdown report'`
- **For your exploitation queue:** `node save_deliverable.js XSS_QUEUE '{"vulnerabilities": [...]}'`
</available_tools>
<data_format_specifications>
<exploitation_queue_format>
Purpose: Defines the structure for a "exploitation queue" saved to `deliverables/xss_exploitation_queue.json` via the Write tool.
Purpose: Defines the structure for a "exploitation queue" saved via the save_deliverable script with type XSS_QUEUE.
Structure: The vulnerability JSON object MUST follow this exact format:
{
"ID": "unique ID for each vulnerability json (XSS-VULN-XX)",
@@ -175,8 +176,8 @@ This rulebook is used for the **Early Termination** check in Step 2.
- 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 Write tool to save the finding to `deliverables/xss_exploitation_queue.json`, 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 report (deliverables/xss_analysis_deliverable.md).
- 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**
@@ -267,20 +268,16 @@ These input vectors were traced and confirmed to have robust, context-appropriat
## Exploitation Queue (MANDATORY)
Regardless of whether vulnerabilities are found, you MUST create:
`deliverables/xss_exploitation_queue.json`
using the **Write tool**.
Regardless of whether vulnerabilities are found, you MUST create the exploitation queue using the save_deliverable script.
- **If exploitable vulnerabilities found:**
Add each exploitable XSS vulnerability (verdict: "vulnerable") using the `exploitation_queue_format` when writing the file. Set `externally_exploitable` to `true` ONLY if exploitable via public internet without internal access.
Use `node save_deliverable.js XSS_QUEUE '{"vulnerabilities": [...]}'` with each exploitable XSS vulnerability (verdict: "vulnerable") following the `exploitation_queue_format`. Set `externally_exploitable` to `true` ONLY if exploitable via public internet without internal access.
- **If no exploitable vulnerabilities found:**
Create an empty file by using the Write tool to save the following JSON:
Use `node save_deliverable.js XSS_QUEUE '{"vulnerabilities": []}'`
```json
{"vulnerabilities": []}
```
- **QUEUE INCLUSION CRITERIA:** ONLY include vulnerabilities where `externally_exploitable = true`. Exclude any vulnerability requiring internal network access, VPN, or direct server access.
This file is the mandatory handoff to the Exploitation phase.
</exploitation_queue_requirements>
@@ -288,9 +285,9 @@ This file is the mandatory handoff to the Exploitation phase.
COMPLETION REQUIREMENTS (ALL must be satisfied):
1. Systematic Analysis: ALL input vectors identified from the reconnaissance deliverable must be analyzed.
2. Deliverable Generation: Both required files must be successfully created:
- deliverables/xss_analysis_deliverable.md (Created)
- deliverables/xss_exploitation_queue.json (Created)
2. Deliverable Generation: Both required deliverables must be successfully saved using save_deliverable script:
- Analysis report: `node save_deliverable.js XSS_ANALYSIS 'your report'`
- Exploitation queue: `node save_deliverable.js XSS_QUEUE '{"vulnerabilities": [...]}'`
ONLY AFTER both systematic analysis AND successful file generation, announce "XSS ANALYSIS COMPLETE" and stop.
ONLY AFTER both systematic analysis AND successful deliverable generation, announce "XSS ANALYSIS COMPLETE" and stop.
</conclusion_trigger>