SSRF in Angular SSR request handling pipeline

Repository is a small standalone Python proof-of-concept exploit with 3 files: LICENSE, README.md, and a single executable script (code.py). The script targets Angular Universal/SSR applications that unsafely process forwarding headers and potentially prototype-pollution-style input. Its main capabilities are: (1) testing header injection behavior using crafted X-Forwarded-* and X-Original-URL headers, (2) attempting SSRF against internal and cloud metadata endpoints by placing internal URLs into trusted forwarding headers, (3) scanning for success indicators in returned content such as metadata, IAM, token, elastic, redis, admin, and profile strings, and (4) attempting sensitive data extraction from AWS metadata endpoints, including token and IAM role data. The exploit uses Python requests with a Session object, accepts a target URL and optional SSL verification bypass, and runs through a fixed sequence: test_header_injection(), exploit_ssrf_chain(), extract_sensitive_data(), then generate_report(). The README mirrors the exploit intent and usage examples. This is not framework-based code and is more than a detector: it actively sends exploitation requests and attempts credential/metadata retrieval, though payloads and targets are largely hardcoded, making it operational but not highly modular.

Repository contains a small Python proof-of-concept targeting an alleged Angular Universal/SSR issue (README labels it CVE-2026-27739) focused on abusing unsafe trust of forwarded headers to achieve SSRF and header manipulation. Structure: - README.md: Describes the attack idea (X-Forwarded-For pointing to cloud metadata), usage examples, and a vulnerable Angular SSR pattern where req.headers are forwarded to internal fetches. It also includes a pasted/truncated code fragment referencing report generation. - code.py: Main exploit script (entry point via shebang). Implements class AngularSSRExploit with three main phases: 1) test_header_injection(): Sends GET requests with crafted headers and a prototype-pollution style query string to look for error/response indicators. 2) exploit_ssrf_chain(): Iterates a hardcoded list of internal targets (AWS IMDS, GCP metadata, localhost admin, Elasticsearch, Redis) and calls ssrf_via_headers() which sets X-Forwarded-For/X-Original-URL/etc. to the internal URL and checks the returned response body for keywords suggesting SSRF success. 3) extract_sensitive_data(): Attempts an AWS IMDSv2-style token/credential extraction by sending X-Forwarded-For to the token endpoint and regex-searching the target’s response for a token-like field, then reusing it in an X-Metadata-Token header to query IAM security credentials. Notable limitations/quality notes: - The script assumes the target will reflect SSRF-fetched content in the HTTP response body; it uses simple keyword matching. - The IMDSv2 flow is not accurate to AWS’s required PUT + X-aws-ec2-metadata-token-ttl-seconds semantics; it instead performs GET and looks for a token in returned text, so real-world success is uncertain. - generate_report() is truncated in the provided content; README suggests writing a report file, but code.py’s report generation appears incomplete here. Overall purpose: a network-based PoC to validate and demonstrate header-based SSRF and related header injection risks in Angular SSR/Universal deployments that forward untrusted headers/URLs to internal requests, with emphasis on cloud metadata exposure.