signed-url-proxy-abuse

Tests HMAC-signed proxy URL architectures for signing oracles, normalization mismatches, and SSRF impact.

7|4|Updated Jun 22, 2026
One-click install
npx skills add https://github.com/dbx0/skills --skill signed-url-proxy-abuse-dbx0
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: signed-url-proxy-abuse
Source: https://github.com/dbx0/skills/tree/main/skills/web-appsec/server-side/signed-url-proxy-abuse
Command: npx skills add https://github.com/dbx0/skills --skill signed-url-proxy-abuse-dbx0

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When a client reaches backends only through a proxy that fetches HMAC-signed, base64-encoded target URLs, testers often stop at "the URL is integrity-protected" and miss the real bugs. This Skill provides a methodology for attacking that indirection: finding endpoints that sign attacker input, detecting signer-versus-fetcher normalization mismatches, and proving whether any of it produces actual SSRF impact. ## Core Features & Use Cases - Corpus harvesting and decoding: Decode pre-signed proxy URLs from discovery/config endpoints and inspect signature structure (version byte, key id, HMAC shape) to confirm keys are not forgeable offline. - Signing oracle discovery: Hunt unauthenticated endpoints whose responses contain freshly signed proxy URLs, then probe how much of the signed URL (path vs host) attacker input controls. - Normalization mismatch testing: Compare fetcher behavior across encoded payloads (%2F, %252F, overlong UTF-8, null bytes) against a baseline to prove the signer and fetcher disagree on the URL. - False-positive discipline: Requires every apparent success to be compared against direct access to the same target, so path manipulation that reaches nothing new is not reported as SSRF. - Use Case: During a fintech web assessment, you find /api/inviter/<slug> returning signed proxy URLs; use this methodology to test host-escape payloads, detect double-decoding at the fetcher, and correctly conclude no impact when traversal only reaches already-public hosts. ## Quick Start Analyze the signed proxy URLs from my target's discovery endpoint and test whether the signing oracle lets me escape the host or reach internal services.

Frequently Asked Questions about signed-url-proxy-abuse

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test a signed URL proxy for SSRF?

First find a signing oracle: an endpoint that returns freshly signed proxy URLs containing your input. Then probe how much of the URL you control with encoded traversal payloads, and confirm impact only if the proxy reaches something you cannot access directly.

What is a signing oracle in proxy URL attacks?

A signing oracle is any endpoint that takes attacker input and returns a freshly HMAC-signed proxy URL. They exist in dynamic flows like invite links or share URLs, and they let you obtain valid signatures for partially attacker-controlled targets.

Can HMAC-signed proxy URLs be forged offline?

No. The signature is an HMAC computed with a server-side key, so offline forgery is not feasible. The practical attack is finding signing oracles and exploiting normalization differences between the component that signs the URL and the component that fetches it.

Why does path traversal through a signed proxy not count as SSRF?

If the traversed path lands on hosts you can already reach directly and returns identical responses, you gained nothing. SSRF requires the proxy to reach something demonstrably inaccessible to you, such as link-local addresses, internal-only names, or endpoints the proxy accesses with injected credentials.

What is signer versus fetcher normalization mismatch?

The signer computes the MAC over one byte sequence while the fetcher may decode further before requesting. If the fetcher decodes %2F or double-decodes %252F, the fetched URL differs from the signed URL, which you detect by comparing response statuses against a clean baseline.