Restore direct validation guidance in existing skills

strix/skills/vulnerabilities/header_injection.md

@@ -122,7 +122,7 @@ The `X-Forwarded-*` family is informational — there is no protocol guarantee a
 - Trace which request fields survive the redirect: content type, handler, method, authorization result, path, and environment.
 - Test whether response metadata is reused as an internal handler, proxy target, template type, or interpreter selection.
 - Compare direct access controls with the internally dispatched resource. A protected URL may be unreachable directly while the same handler is invokable through a clean internal redirect.
-- Treat CRLF injection and response-controlling SSRF as possible inputs to this chain, then validate handler selection with a tester-created benign route or marker before using a privileged handler.
+- Treat CRLF injection and response-controlling SSRF as possible inputs to this chain, then validate handler selection before using a privileged handler.
 
 ### XSS via Response Headers
 

strix/skills/vulnerabilities/insecure_file_uploads.md

@@ -28,13 +28,13 @@ Upload surfaces are high risk: server-side execution (RCE), stored XSS, malware
 - Small probe files of each claimed type; diff resulting Content-Type, Content-Disposition, and X-Content-Type-Options on download
 - Magic bytes vs extension: JPEG/GIF/PNG headers; mismatches reveal reliance on extension or MIME sniffing
 - SVG/HTML probe: do they render inline (text/html or image/svg+xml) or download (attachment)?
-- Archive probe: in a disposable lab sandbox, use a small archive with a bounded traversal entry or symlink to detect extraction rules
+- Archive probe: simple zip with nested path traversal entries and symlinks to detect extraction rules
 
 ## Detection Channels
 
 ### Server Execution
 
-- Inert/no-op interpreter or template markers first; executable web shells or config/handler uploads (.htaccess, .user.ini, web.config) only when the requested test requires server execution
+- Web shell execution (language dependent), config/handler uploads (.htaccess, .user.ini, web.config) enabling execution
 - Interpreter-side template/script evaluation during conversion (ImageMagick/Ghostscript/ExifTool)
 
 ### Client Execution
@@ -69,12 +69,11 @@ Upload surfaces are high risk: server-side execution (RCE), stored XSS, malware
 - Magic-byte spoofing: valid JPEG header then embedded script; verify server uses content inspection, not extensions alone
 - Detector/consumer differential: make the upload validator and the later parser disagree about type, structure, or validity
 - Probe detector scan windows, recursion/nesting limits, maximum bytes inspected, invalid-syntax recovery, and version-specific magic databases
-- Prefer ambiguous leading bytes or tightly bounded nesting over oversized files; deep nesting and scan-limit exhaustion are disposable-lab resource tests with byte/depth/time ceilings
 
 ### Archive Attacks
 
 - Zip Slip: entries with `../../` to escape extraction dir; symlink-in-zip pointing outside target; nested zips
-- Zip bomb: extreme compression ratios to exhaust processors; treat as an offline/disposable-lab DoS test with compressed/uncompressed byte, depth, CPU, memory, and time ceilings
+- Zip bomb: extreme compression ratios to exhaust resources in processors
 
 ### Toolchain Exploits
 
@@ -104,11 +103,11 @@ Upload surfaces are high risk: server-side execution (RCE), stored XSS, malware
 ### Processing Races
 
 - Request file immediately after upload but before AV/CDR completes
-- Trigger bounded conversions in a disposable lab to study race windows; large images/deep PDFs are resource-exhaustion tests, not routine race probes
+- Trigger heavy conversions (large images, deep PDFs) to widen race windows
 
 ### Metadata Abuse
 
-- Oversized EXIF/XMP/IPTC blocks to trigger parser flaws only in an offline/disposable parser lab with explicit size and resource ceilings
+- Oversized EXIF/XMP/IPTC blocks to trigger parser flaws
 - Payloads in document properties of Office/PDF rendered by previewers
 
 ### Header Manipulation

strix/skills/vulnerabilities/path_traversal_lfi_rfi.md

@@ -169,7 +169,7 @@ Then inventory generic execution and influence surfaces:
 
 Do not require the malicious file to be directly web-accessible. An HTTP extension allowlist can block `/path/payload.ext` while an internal view engine, autoloader, or interpreter still opens and executes that file through a clean route. Trace public request filtering and internal file resolution as separate security boundaries.
 
-Test search order with syntax-valid non-executable/no-op marker files or filesystem traces in a tester-owned candidate path. Trigger the normal route/action that causes internal resolution. Record whether the framework creates, compiles, caches, or executes the artifact and what reload condition is required.
+Test search order with candidate marker files or filesystem traces. Trigger the normal route/action that causes internal resolution. Record whether the framework creates, compiles, caches, or executes the artifact and what reload condition is required.
 
 ## Testing Methodology
 
@@ -186,8 +186,8 @@ Test search order with syntax-valid non-executable/no-op marker files or filesys
 1. Show a minimal traversal read proving out-of-root access (e.g., `/etc/hosts`) with a same-endpoint in-root control
 2. For LFI, demonstrate inclusion of a benign local file or harmless wrapper output (`php://filter` base64 of index.php)
 3. For RFI, prove remote fetch by OAST or controlled output; avoid destructive payloads
-4. For Zip Slip, use an outer disposable lab sandbox and create an archive with `../` entries that writes a marker outside the inner extraction target
-5. For file-write chains, first prove a benign canary is created at the intended path, then prove the normal resolver loads it; document cache/reload requirements
+4. For Zip Slip, create an archive with `../` entries and show write outside target (e.g., marker file read back)
+5. For file-write chains, first prove a canary is created at the intended path, then prove the normal resolver loads it; document cache/reload requirements
 6. Provide before/after file paths, exact requests, and content hashes/lengths for reproducibility
 
 ## False Positives

strix/skills/vulnerabilities/subdomain_takeover.md

@@ -122,14 +122,14 @@ TLS clues: certificate CN/SAN referencing provider default host instead of the c
 2. **Resolve DNS** - All RR types: A/AAAA, CNAME, NS, MX, TXT; keep CNAME chains
 3. **HTTP/TLS probe** - Capture status, body, error text, Server headers, certificate SANs
 4. **Fingerprint providers** - Map known "unclaimed/missing resource" signatures
-5. **Attempt claim** (only with written authorization and containment) - Create or bind the exact missing resource after determining whether doing so can receive existing third-party traffic
+5. **Attempt claim** (with authorization) - Create missing resource with exact required name
 6. **Validate control** - Serve minimal unique payload; confirm over HTTPS
 
 ## Validation
 
 1. Before: record DNS chain, HTTP response (status/body length/fingerprint), and TLS details
 2. After claim: serve unique content and verify over HTTPS at the target subdomain
-3. Confirm HTTPS/custom-domain control when it is required for the consumer; public DV issuance is a durable CT side effect and should be used only when explicitly authorized and necessary to establish claimability
+3. Optional: issue a DV certificate (legal scope) and reference CT entry as evidence
 4. Demonstrate impact chains (CSP/script-src trust, OAuth redirect acceptance, cookie Domain scoping)
 
 ## Severity
@@ -137,7 +137,7 @@ TLS clues: certificate CN/SAN referencing provider default host instead of the c
 - Score severity based on current claimability plus trusted-origin impact, not just a provider-branded error page
 - When evaluating severity, use `web_search` (if available) for the exact provider/product to confirm whether it now enforces subdomain takeover prevention such as TXT/custom-domain ownership verification or reserved-hostname protections; if search is unavailable, do not treat that absence as evidence that the provider prevents claiming
 - If you have positively confirmed the provider currently prevents third-party claiming and you cannot bypass that control, treat the finding as low severity rather than a confirmed takeover — an unconfirmed provider control is not grounds for downgrading
-- Reserve high/critical severity for cases where you can claim the resource or strongly prove claimability and show meaningful impact such as OAuth redirect abuse, cookie scope abuse, CSP trust, email receipt, or NS delegation control.
+- Reserve high/critical severity for cases where you can claim the resource or strongly prove claimability and show meaningful impact such as OAuth redirect abuse, cookie scope abuse, CSP trust, email receipt, or NS delegation control. E.g. Elastic Beanstalk takeovers are still generally legitimate.
 
 ## False Positives
 
@@ -159,7 +159,7 @@ TLS clues: certificate CN/SAN referencing provider default host instead of the c
 3. Prefer minimal PoCs: static "ownership proof" page and, where allowed, DV cert issuance
 4. Monitor CT for unexpected certs on your subdomains
 5. Eliminate dangling DNS in decommission workflows first
-6. For NS delegations, establish live delegation, registrability/control, accepted authoritative responses, and the affected namespace before assigning severity
+6. For NS delegations, treat any expired nameserver domain as critical
 7. Use CAA to limit certificate issuance while you triage
 
 ## Summary